Re: [PATCH] kmemleak: Reduce verbosity when memory allocation fails

[Catalin Marinas]

On Monday, 10 January 2011, David Rientjes <rientjes@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/