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: <200708201838.50262.nigel@nigel.suspend2.net>
Date:	Mon, 20 Aug 2007 18:38:48 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

Hi.

On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > Hi all.
> > 
> > In current git (and for a while now), an attempt to allocate memory with 
> > GFP_ATOMIC will fail if we're below the low watermark level. The only way 
to 
> > access that memory that I can see (not that I've looked that hard) is to 
have 
> > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
correct. 
> > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
GFP_KERNEL?
> > 
> > The following patch is a potential fix for GFP_ATOMIC.
> 
> Sorry, no.
> 
> GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> and hence can sleep and wait for reclaim so that should not be a problem
> (usually).
> 
> GFP_ATOMIC may not access the reserves because the reserves are needed
> to get out of OOM deadlocks within the VM. Consider the fact that
> freeing memory needs memory - if there is no memory free, you cannot
> free memory and you're pretty much stuck.

I guess, then, the question should be whether the watermark values are 
appropriate. Do we need high order allocations watermarked if this is the 
only purpose, particularly considering that whatever memory is allocated for 
this purpose is essentially useless 99.9% of the time?

Regards,

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ