Re: [PATCH] kmemleak: Ignore the aperture memory hole on x86_64

[Catalin Marinas]

On Sat, 2009-08-15 at 15:17 +0100, Ingo Molnar wrote:
> * Catalin Marinas <catalin.marinas@xxxxxxx> 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? 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.

Thanks.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/