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: <alpine.DEB.2.00.0906171401440.7198@chino.kir.corp.google.com>
Date:	Wed, 17 Jun 2009 14:12:50 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	"David S. Miller" <davem@...emloft.net>,
	Justin Piszcz <jpiszcz@...idpixels.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] ipv4: don't warn about skb ack allocation failures

On Wed, 17 Jun 2009, Eric Dumazet wrote:

> > Yes, if they are recoverable without any side effects.  Otherwise, they 
> > will continue to emit page allocation failure messages which cause users 
> > to waste their time when they recognize a problem of an unknown 
> > seriousness level in both reporting the issue and looking for resulting 
> > corruption.  The __GFP_NOWARN annotation suppresses such warnings for 
> > those very reasons.
> 
> Then why emit the warning at first place ?
> 
> Once we patch all call sites to use GFP_ATOMIC | __GFP_NOWARN, I bet 99% 
> GFP_ATOMIC allocations in kernel will use it, so we go back to silent mode.
> 
> If a GFP_ATOMIC call site *cannot* use __GFP_NOWARN, it will either :
> 
> - call panic()
> - crash with a nice stack trace because caller was not aware NULL could be
> returned by kmalloc()
> 
> 
> Maybe GFP_ATOMIC should include __GFP_NOWARN
> 
> #define GFP_ATOMIC  (__GFP_HIGH)
> ->
> #define GFP_ATOMIC  (__GFP_HIGH | __GFP_NOWARN)
> 

You must now mask off __GFP_NOWARN in the gfp flags for the allocation if 
you have a GFP_ATOMIC allocation that wants the page allocation failure 
warning messages.  That message includes pertinent information with regard 
to the state of the VM that is otherwise unavailable by a BUG_ON() or NULL 
pointer dereference.

For example, I could only diagnose Justin's failure as a harmless page 
allocator warning because I could identify its caller, the gfp mask of the 
allocation attempt, and the memory available.  It would not have otherwise 
been possible to find that the system was actually oom.

The general principle is that it is up to the caller to know whether an 
allocation failure is recoverable or not and not up to any VM 
implementation.
--
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