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]

Date:	Mon, 10 Jan 2011 15:31:59 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Catalin Marinas <catalin.marinas@....com>
cc:	"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 Mon, 10 Jan 2011, Catalin Marinas wrote:

> > 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.
> 

Yes, __GFP_REPEAT is a no-op for order-0 allocations for the current 
implementation.

> If the user calling the kernel alloc function cannot get memory,
> kmemleak won't be called anyway.
> 

I'm talking about when the allocation is successful and the metadata 
allocation is not, such as what Toralf reported.  If you pass 
__GFP_NOFAIL, it's going to loop forever which is certainly not what we'd 
want: we'd rather just disable kmemleak and continue doing work.  If you 
pass __GFP_NOMEMALLOC, then kmemleak can allocate from memory reserves in 
the reclaim path which is not allowed.  And if you don't pass 
__GFP_HARDWALL, then these allocations can break memory isolation by 
allowing the metadata to be allocated from different cpusets.

In other words, I'm pretty sure you don't want to be masking these options 
off of the caller allocation when passed.  It makes no sense for the user 
to do a GFP_KERNEL | __GFP_NORETRY allocation and then have kmemleak loop 
forever.