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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTik-NwSioPg96EFUDzuK=zK0kNbvUeQbt0rwQAtX@mail.gmail.com>
Date:	Mon, 10 Jan 2011 22:00:39 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Toralf Förster <toralf.foerster@....de>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"Ted Ts'o" <tytso@....edu>
Subject: Re: [PATCH] kmemleak: Reduce verbosity when memory allocation fails

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