lkml.org 
[lkml]   [2009]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kmemleak: Ignore the aperture memory hole on x86_64

* Catalin Marinas <catalin.marinas@arm.com> wrote:

> On Sat, 2009-08-15 at 15:17 +0100, Ingo Molnar wrote:
> > * Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > + /*
> > > + * Kmemleak should not scan this block as it may not be mapped via the
> > > + * kernel direct mapping.
> > > + */
> > > + kmemleak_ignore(p);
> >
> > More importantly, kmemleak should _never_ do the garbage collection
> > scan for device memory (such as the agp aperture above). All the
> > aperture areas are in that category - PCI aperture, IOMMU areas,
> > etc. etc.
> >
> > Please double check that kmemleak does not check those - there are
> > devices where pure reading of that address space can have
> > side-effects.
>
> I'll do a grep. But would such memory still be mapped in the
> kernel direct mapping? [...]

It should not be mapped directly - we try to map all kinds of
resources 'precisely', so that there can be no cache aliasing
complications due to over-mapping - but still, there are
compatibility ranges that are always mapped (the BIOS area for
example).

> [...] In this particular case, it was alloc_bootmem() memory which
> seems to have been unmapped (and cause an oops), otherwise, at
> least on some architectures, may have problems with speculative
> fetches.
>
> Kmemleak doesn't track other mappings like ioremap, so it should
> not scan device memory.
>
> Since you raised this, I realised there is a class of kmalloc'ed
> memory blocks that may have some issues on non-coherent
> architectures. If such blocks are used for DMA and cache
> invalidation is only done in dma_map_single(FROM_DEVICE) (the ARM
> case), kmemleak scanning before dma_unmap_single() may pollute the
> cache. One solution is to invalidate the caches again in
> dma_unmap_single(). I'm not sure ignoring GFP_DMA blocks would be
> feasible if this flag is used for other blocks containing
> pointers. I need to do some tests but I don't think x86 is
> affected.

Yeah, x86 shouldnt be affected.

Ingo


\
 
 \ /
  Last update: 2009-08-16 09:07    [W:0.157 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site