Messages in this thread | | | Date | Mon, 10 Jan 2011 22:00:39 +0000 | Subject | Re: [PATCH] kmemleak: Reduce verbosity when memory allocation fails | From | Catalin Marinas <> |
| |
On Monday, 10 January 2011, David Rientjes <rientjes@google.com> wrote: > On Mon, 10 Jan 2011, Catalin Marinas wrote: > >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c >> index bd9bc21..eee8e31 100644 >> --- a/mm/kmemleak.c >> +++ b/mm/kmemleak.c >> @@ -113,7 +113,8 @@ >> #define BYTES_PER_POINTER sizeof(void *) >> >> /* GFP bitmask for kmemleak internal allocations */ >> -#define GFP_KMEMLEAK_MASK (GFP_KERNEL | GFP_ATOMIC) >> +#define gfp_kmemleak_mask(gfp) ((gfp) & (GFP_KERNEL | GFP_ATOMIC) | \ >> + __GFP_NOWARN) > > It would be a shame if the allocation were __GFP_NORETRY and kmemleak > ended up looping forever because it suppresses the bit for a single page, > it uses __GFP_NOMEMALLOC and kmemleak ends up allocating from memory > reserves, or it uses __GFP_HARDWALL and kmemleak is allocating metadata in > a different cpuset. > > I'm not sure why you're not just masking __GFP_NOFAIL and __GFP_REPEAT and > then failing gracefully? (And __GFP_ZERO and __GFP_COMP, too, of course.)
The reason I wouldn't allow kmemleak allocations to fail is that once it happened kmemleak cannot recover. Once it missed an allocation for its metadata, the corresponding memory block cannot be tracked nor scanned leading to false positives. I had thought about even passing __GFP_REPEAT but I think this is kind of implied for 0-order allocations.
If the user calling the kernel alloc function cannot get memory, kmemleak won't be called anyway.
-- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |