[PATCHv8 00/12] Contiguous Memory Allocator

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of Russell King -
> ARM Linux
> Sent: Tuesday, January 04, 2011 10:49 PM
> To: Johan MOSSBERG
> Cc: Daniel Walker; Kyungmin Park; Mel Gorman; KAMEZAWA Hiroyuki;
> Michal Nazarewicz; linux-kernel at vger.kernel.org; Michal Nazarewicz;
> linux-mm at kvack.org; Ankita Garg; Andrew Morton; Marek Szyprowski;
> linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [PATCHv8 00/12] Contiguous Memory Allocator
>
> On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote:
> > Russell King wrote:
> > > Has anyone addressed my issue with it that this is wide-open for
> > > abuse by allocating large chunks of memory, and then remapping
> > > them in some way with different attributes, thereby violating
> the
> > > ARM architecture specification?
> >
> > I seem to have missed the previous discussion about this issue.
> > Where in the specification (preferably ARMv7) can I find
> > information about this?
>
> Here's the extracts from the architecture reference manual:
>
> * If the same memory locations are marked as having different
>   cacheability attributes, for example by the use of aliases in a
>   virtual to physical address mapping, behavior is UNPREDICTABLE.
>
> A3.5.7 Memory access restrictions
>
> Behavior is UNPREDICTABLE if the same memory location:
> * is marked as Shareable Normal and Non-shareable Normal
> * is marked as having different memory types (Normal, Device, or
>   Strongly-ordered)
> * is marked as having different cacheability attributes
> * is marked as being Shareable Device and Non-shareable Device
> memory.
>
> Such memory marking contradictions can occur, for example, by the
> use of
> aliases in a virtual to physical address mapping.
>
> Glossary:
> UNPREDICTABLE
> Means the behavior cannot be relied upon. UNPREDICTABLE behavior
> must not
> represent security holes.  UNPREDICTABLE behavior must not halt or
> hang
> the processor, or any parts of the system. UNPREDICTABLE behavior
> must not
> be documented or promoted as having a defined effect.
>
> > Is the problem that it is simply
> > forbidden to map an address multiple times with different cache
> > setting and if this is done the hardware might start failing? Or
> > is the problem that having an address mapped cached means that
> > speculative pre-fetch can read it into the cache at any time,
> > possibly causing problems if an un-cached mapping exists? In my
> > opinion option number two can be handled and I've made an attempt
> > at doing that in hwmem (posted on linux-mm a while ago), look in
> > cache_handler.c. Hwmem currently does not use cma but the next
> > version probably will.
>
> Given the extract from the architecture reference manual, do you
> want
> to run a system where you can't predict what the behaviour will be
> if
> you have two mappings present, one which is cacheable and one which
> is
> non-cacheable, and you're relying on the non-cacheable mapping to
> never
> return data from the cache?
>
> What if during your testing, it appears to work correctly, but out
> in
> the field, someone's loaded a different application to your setup
> resulting in different memory access patterns, causing cache lines
> to
> appear in the non-cacheable mapping, and then the CPU hits them on
> subsequent accesses corrupting data...
>
> You can't say that will never happen if you're relying on this
> unpredictable behaviour.
>
Just to add to Russell's point, we did land up in un-traceable
CPU deadlocks while running the kernel which was violating some of
the rules set by ARM ARM.
The usecase use to work ~98% of the time.

Regards,
Santosh