On 9/14/15, Catalin Marinas <catalin.mari...@arm.com> wrote: > On Mon, Sep 14, 2015 at 07:36:49PM +1000, Michael Ellerman wrote: >> On Mon, 2015-09-14 at 10:15 +0100, Catalin Marinas wrote: >> > 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. > > Other kmemleak annotations throughout the kernel are usually added > immediately after the allocation place (since that's what kmemleak > reports as a leak). > >> That way if someone starts calling alloc/free from a hotplug path for >> example, >> kmemleak will still notice that free isn't really freeing. > > Kmemleak would only notice the moment you clear the last reference to > the allocated memory block (like bmp->bitmap = NULL), so this patch > should work as along as "freeing" is done via msi_bitmap_free().
Ok, I'll move kmemleak annotaion for the bitmap inside the test_basics() plus add a flag into msi_bitmap to test for the type of allocation though the slab_is_available() Thank you. > > BTW, you can even use kmemleak_ignore(). The difference is that the > bitmap won't be scanned by kmemleak and that's fine since it doesn't > contain any pointers. > > -- > Catalin > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
