linux-kernel - Re: [patch] mm, page_alloc: allow __GFP_NOFAIL to allocate below watermarks after reclaim

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 12 Dec 2013 12:10:38 +1100
From:	Dave Chinner <david@...morbit.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] mm, page_alloc: allow __GFP_NOFAIL to allocate below
 watermarks after reclaim

On Tue, Dec 10, 2013 at 03:03:39PM -0800, David Rientjes wrote:
> On Tue, 10 Dec 2013, Mel Gorman wrote:
> 
> > > If direct reclaim has failed to free memory, __GFP_NOFAIL allocations
> > > can potentially loop forever in the page allocator.  In this case, it's
> > > better to give them the ability to access below watermarks so that they
> > > may allocate similar to the same privilege given to GFP_ATOMIC
> > > allocations.
> > > 
> > > We're careful to ensure this is only done after direct reclaim has had
> > > the chance to free memory, however.
> > > 
> > > Signed-off-by: David Rientjes <rientjes@...gle.com>
> > 
> > The main problem with doing something like this is that it just smacks
> > into the adjusted watermark if there are a number of __GFP_NOFAIL. Who
> > was the user of __GFP_NOFAIL that was fixed by this patch?
> > 
> 
> Nobody, it comes out of a memcg discussion where __GFP_NOFAIL were 
> recently given the ability to bypass charges to the root memcg when the 
> memcg has hit its limit since we disallow the oom killer to kill a process 
> (for the same reason that the vast majority of __GFP_NOFAIL users, those 
> that do GFP_NOFS | __GFP_NOFAIL, disallow the oom killer in the page 
> allocator).
> 
> Without some other thread freeing memory, these allocations simply loop 
> forever.

So what is kswapd doing in this situation?

> Since there are comments in both gfp.h and page_alloc.c that say no new 
> users will be added, it seems legitimate to ensure that the allocation 
> will at least have a chance of succeeding, but not the point of depleting 
> memory reserves entirely.

As it said before, the filesystem will then simply keep allocating
memory until it hits the next limit, and then you're back in the
same situation. Moving the limit at which it fails does not solve
the problem at all.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/