On Mon, 2015-09-14 at 10:15 +0100, Catalin Marinas wrote: > On Mon, Sep 14, 2015 at 04:04:37PM +1000, Michael Ellerman wrote: > > On Sun, 2015-09-13 at 21:36 +0300, Denis Kirjanov wrote: > > > The comment in msi_bitmap_free() states that we can't free > > > the bitmap so mark it with the kmemleak_not_leak(). > > > > Yeah, and I've always hated that comment :) > > > > I assume it's still true now that we don't use bootmem? > > If it's not bootmem, it's probably memblock. Looking at the code, it > seems that msi_bitmap_free() cannot make the distinction between a slab > allocation and a bootmem/memblock one (allocated via > zalloc_maybe_bootmem).
Yeah it is memblock these days. > You could add some flag to struct msi_bitmap based on mem_init_done to > be able to reclaim some slab memory later. If the bitmap is small and > such allocation doesn't happen outside boot, it may not be worth the > effort. Right, I think that's the only solution, and it's not quite worth the trouble because it's generally not freed at all, except via error paths. Still I think it would be better to move the kmemleak annotation into the msi bitmap test code, or maybe a wrapper that's called by the test code. That way if someone starts calling alloc/free from a hotplug path for example, kmemleak will still notice that free isn't really freeing. cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
