Kernel related (?) user space crash at ARM11 MPCore

[Shilimkar, Santosh]

Catalin,
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-
> kernel-bounces at lists.infradead.org] On Behalf Of Catalin Marinas
> Sent: Monday, September 21, 2009 3:32 AM
> To: Russell King - ARM Linux
> Cc: Dirk Behme; linux-arm-kernel at lists.infradead.org
> Subject: Re: Kernel related (?) user space crash at ARM11 MPCore
> 
> Russell King - ARM Linux wrote:
> > On Sun, Sep 20, 2009 at 09:39:00AM +0100, Catalin Marinas wrote:
> >> On Sat, 2009-09-19 at 23:40 +0100, Russell King - ARM Linux wrote:
> >>> On Mon, Aug 17, 2009 at 06:25:16PM +0100, Catalin Marinas wrote:
> >>>> Assuming that the dynamic linker does instruction modifications as
> well
> >>>> and expects the mprotect(RX) to flush the caches, the patch below
> >>>> appears to fix the problem (not intensively tested). Note that I
> don't
> >>>> say this is the right fix but it may work around the problem until
> >>>> further investigation into the dynamic linker.
> >>> Having now re-read the start of the thread, and put all the pieces
> >>> together, the problem is not to do with SMP per-se, or Icache
> >>> problems.
>  >>
> >> It's the I-D cache coherency.
> >
> > You may be right, but the current evidence does not support that.
> > If what you say is true, then all current ARMv6 and ARMv7 non-SMP
> > systems would be affected.  So far, the bug report is only against
> > SMP systems, where the cache is always forced to write allocate mode.
> 
> It is quite unlikely, though not impossible, for the I-cache to have
> stale entries. That's mainly because by the time a page cache page is
> reused for a different file, the corresponding I-cache entries are long
> gone. You could try on a software model to limit the amount of RAM and
> increase the I-cache size (I think AEM supports pseudo-infinite caches).
> 
> Data (instruction opcodes) not reaching the RAM because of
> write-allocate D-cache is the main issue, but it would be better to
> cover the I-cache coherency to avoid hard to reproduce bugs on some
> hardware configurations.
> 
> >>> I'd like to request that someone who can prove that the program works
> >>> on ARMv6/v7 hardware does the following test:
> >>>
> >>> 1. boot the system with cachepolicy=writealloc
> >>> 2. re-test the program
>  >>
> >> I don't think this would work. All the non-SMP v6/v7 processors I'm
> >> aware of only support read-allocate caches, even if you try to force
> >> write-allocate. On the SMP ones (Cortex-A9, ARM11MPCore), write-
> allocate
> >> is the default.
> >
> > Are you sure - I thought some of them did support write allocate.
> 
> I'm not entirely sure but that's what I recall. Anyway, you can run a UP
> kernel on ARM11MPCore.

Even though this thread is mainly focused on SMP + WA cache, can you point out some reference which support your argument that " the non-SMP v6/v7 processors I'm aware of only support read-allocate caches, even if you try to force write-allocate". Mainly Cortex-a8 (ARMv7). The Cortex-A8 TRM says that it does support WBWA cache.

Thanks!!

Regards,
Santosh