Messages in this thread | | | Subject | Re: [PATCH] kmemleak: Only use GFP_KERNEL|GFP_ATOMIC for the internal allocations | From | Catalin Marinas <> | Date | Wed, 17 Jun 2009 14:23:27 +0100 |
| |
On Wed, 2009-06-17 at 16:01 +0300, Pekka Enberg wrote: > On Wed, Jun 17, 2009 at 3:52 PM, Catalin Marinas<catalin.marinas@arm.com> wrote: > > Kmemleak allocates memory for pointer tracking and it tries to avoid > > using GFP_ATOMIC if the caller doesn't require it. However other gfp > > flags may be passed by the caller which aren't required by kmemleak. > > This patch filters the gfp flags so that only GFP_KERNEL | GFP_ATOMIC > > are used. > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > Is this really safe? What if we're in a middle of a filesystem > operation that uses GFP_NOFAIL and all of a sudden kmemleak allocation > fails and causes a panic?
A kmemleak_panic() call only disables the kmemleak but doesn't stop the kernel. The __GFP_NOFAIL allocation had already happened and the pointer returned to the caller.
If we pass the __GFP_NOFAIL flag via the kmemleak's alloc, we get the warning reported by Ingo (though it's not clear to me why this happens as a kmemleak_object cache allocation is 192 bytes on a 32 bit machine).
Are there (common) situations where we expect kmemleak's alloc to fail without __GFP_NOFAIL?
-- Catalin
| |