Messages in this thread | | | Subject | Re: [PATCH] kmemleak: Only use GFP_KERNEL|GFP_ATOMIC for the internal allocations | From | Pekka Enberg <> | Date | Wed, 17 Jun 2009 16:30:48 +0300 |
| |
On Wed, 2009-06-17 at 14:23 +0100, Catalin Marinas wrote: > 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.
Ah, ok. I was confused by the name of kmemleak_panic() (which could use renaming methinks).
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Pekka
| |