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().
next prev parent reply other threads:[~2008-04-02 17:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080401235609.GA6947@codemonkey.org.uk>
[not found] ` <200804021228.16875.nickpiggin@yahoo.com.au>
[not found] ` <47F32789.2070703@redhat.com>
[not found] ` <20080402005646.f8df1c1b.akpm@linux-foundation.org>
2008-04-02 8:17 ` GFP_ATOMIC page allocation failures 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
[not found] ` <200804022012.58760.nickpiggin@yahoo.com.au>
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-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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).