[PATCH] powerpc: msi: mark bitmap with kmemleak_not_leak()
Denis Kirjanov
kda at linux-powerpc.org
Mon Sep 14 20:42:15 AEST 2015
On 9/14/15, Catalin Marinas <catalin.marinas at 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
>
>
More information about the Linuxppc-dev
mailing list