Thread (6 messages) flat view 6 messages, 3 authors, 2015-09-14

Re: [PATCH] powerpc: msi: mark bitmap with kmemleak_not_leak()

From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2015-09-14 10:07:12

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:
quoted
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.
=20
Right, I think that's the only solution, and it's not quite worth the tro=
uble
because it's generally not freed at all, except via error paths.
=20
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 exa=
mple,
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 =3D NULL), so this patch
should work as along as "freeing" is done via msi_bitmap_free().

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.

--=20
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help