All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Chris Snook <csnook@redhat.com>,
	Dave Jones <davej@codemonkey.org.uk>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	NetDev <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: GFP_ATOMIC page allocation failures.
Date: Wed, 2 Apr 2008 10:33:55 -0700	[thread overview]
Message-ID: <20080402103355.77ef22ff.akpm@linux-foundation.org> (raw)
In-Reply-To: <47F3C0A8.9090300@garzik.org>

On Wed, 02 Apr 2008 13:21:44 -0400 Jeff Garzik <jeff@garzik.org> wrote:

> Andrew Morton wrote:
> > The appropriate thing to do here is to convert known-good drivers (such as
> > e1000[e]) to use __GFP_NOWARN.
> > 
> > Unfortunately netdev_alloc_skb() went and assumed GFP_ATOMIC, but I guess
> > we can dive below the covers and use __netdev_alloc_skb():
> > 
> > 
> > 
> > From: Andrew Morton <akpm@linux-foundation.org>
> > 
> > We get rather a lot of reports of page allocation warnings coming out of
> > e1000.  But this driver is know to handle them properly so let's suppress
> > them.
> 
> 
> Do you people hear what you're saying???
> 
> I respectfully but strongly disagree with this.
> 
> We do __not__ need a whitelist (__GFP_NOWARN) of drivers that handle 
> allocation failures properly.  That's a long list, a maintenance 
> nightmare, and it is punishing good behavior.
> 
> It has been true for over a decade that allocations should be checked 
> for NULL, and GFP_ATOMIC allocations MUST be checked for NULL.
> 
> Let's not crap all over good drivers, because a few bad apples don't 
> have the proper checks.
> 
> Or at the very least, this TOTALLY BOGUS spew from working drivers 
> should not be foisted upon users.  Every time a working driver complains 
> about this -- as in the examples here -- the value of the warning 
> decreases to noise.
> 
> And the solution to noise is not _more noise_ (adding 'nowarn' to every 
> damn driver in the kernel).
> 

After you've read Nick's comments (which I pray you have not), and after
you've convinced us and yourself of their wrongness, you might like to
consider adding a __GFP_NOWARN to netdev_alloc_skb().


  reply	other threads:[~2008-04-02 17:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01 23:56 GFP_ATOMIC page allocation failures Dave Jones
2008-04-02  1:28 ` Nick Piggin
2008-04-02  1:35   ` Dave Jones
2008-04-02  6:28     ` Chris Snook
2008-04-02  7:56       ` Andrew Morton
2008-04-02  8:17         ` KOSAKI Motohiro
2008-04-02  8:24           ` David Miller
2008-04-02  8:43             ` Andrew Morton
2008-04-02 10:00             ` KOSAKI Motohiro
2008-04-02 10:56               ` KOSAKI Motohiro
2008-04-02 18:44                 ` David Miller
2008-04-02 20:12                   ` Michael Chan
2008-04-02 20:53                     ` David Miller
2008-04-02 11:04             ` Peter Zijlstra
2008-04-02 18:45               ` David Miller
2008-04-02 19:06                 ` Jeff Garzik
2008-04-02  9:12         ` Nick Piggin
2008-04-02 15:54           ` Andrew Morton
2008-04-03  5:22             ` Nick Piggin
2008-04-03  5:32               ` Andrew Morton
2008-04-03  8:59                 ` Evgeniy Polyakov
2008-06-26 21:06                   ` Dave Jones
2008-06-26 22:26                     ` Chris Snook
2008-06-26 22:26                       ` Chris Snook
2008-06-27 10:01                     ` Evgeniy Polyakov
2008-06-27 10:01                       ` Evgeniy Polyakov
2008-04-02 17:21         ` Jeff Garzik
2008-04-02 17:33           ` Andrew Morton [this message]
2008-04-02 18:18             ` Jeff Garzik
2008-04-02 18:37               ` Kok, Auke
2008-04-03  5:57               ` Nick Piggin
2008-04-03 18:20                 ` Jeff Garzik
     [not found] <adYyJ-20N-11@gated-at.bofh.it>
     [not found] ` <aef6w-6rx-45@gated-at.bofh.it>
     [not found]   ` <aefJ9-7KR-15@gated-at.bofh.it>
     [not found]     ` <aeqF6-45P-29@gated-at.bofh.it>
2008-04-04  9:52       ` Bodo Eggert
2008-04-04  9:52         ` Bodo Eggert
2008-04-04 10:59         ` Nick Piggin
2008-04-04 11:35           ` Bodo Eggert
2008-04-05  1:06             ` Nick Piggin
2008-04-06 12:12               ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080402103355.77ef22ff.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=csnook@redhat.com \
    --cc=davej@codemonkey.org.uk \
    --cc=davem@davemloft.net \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.