From: Andrew Morton <akpm@linux-foundation.org>
To: tytso@mit.edu
Cc: Fabian Frederick <fabf@skynet.be>,
linux-kernel <linux-kernel@vger.kernel.org>,
reiserfs-devel@vger.kernel.org,
David Rientjes <rientjes@google.com>,
Joe Perches <joe@perches.com>
Subject: Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL
Date: Sat, 22 Mar 2014 10:55:24 -0700 [thread overview]
Message-ID: <20140322105524.7baec73a.akpm@linux-foundation.org> (raw)
In-Reply-To: <20140322173207.GC23583@thunk.org>
On Sat, 22 Mar 2014 13:32:07 -0400 tytso@mit.edu wrote:
> On Sat, Mar 22, 2014 at 01:26:06PM -0400, tytso@MIT.EDU wrote:
> > > Well. Converting an existing retry-for-ever caller to GFP_NOFAIL is
> > > good. Adding new retry-for-ever code is not good.
>
> Oh, and BTW --- now that checkpatch.pl now flags an warning whenever
> GFP_NOFAIL is used
I don't know what the basis for this NOFAIL-is-going-away theory could
have been. What's the point in taking a centrally implemented piece of
logic and splattering its implementation out to tens of different
callsites?
Obviously I was asleep when I merged that checkpatch change.
From: Andrew Morton <akpm@linux-foundation.org>
Subject: scripts/checkpatch.pl: __GFP_NOFAIL isn't going away
Revert 7e4915e78992eb ("checkpatch: add warning of future __GFP_NOFAIL use").
There are no plans to remove __GFP_NOFAIL.
__GFP_NOFAIL exists to
a) centralise the retry-allocation-for-ever operation into the core
allocator, which is the appropriate implementation site and
b) permit us to identify code sites which aren't handling memory
exhaustion appropriately.
Cc: David Rientjes <rientjes@google.com>
Cc: Joe Perches <joe@perches.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/checkpatch.pl | 6 ------
1 file changed, 6 deletions(-)
diff -puN scripts/checkpatch.pl~scripts-checkpatchpl-__gfp_nofail-isnt-going-away scripts/checkpatch.pl
--- a/scripts/checkpatch.pl~scripts-checkpatchpl-__gfp_nofail-isnt-going-away
+++ a/scripts/checkpatch.pl
@@ -4240,12 +4240,6 @@ sub process {
"$1 uses number as first arg, sizeof is generally wrong\n" . $herecurr);
}
-# check for GFP_NOWAIT use
- if ($line =~ /\b__GFP_NOFAIL\b/) {
- WARN("__GFP_NOFAIL",
- "Use of __GFP_NOFAIL is deprecated, no new users should be added\n" . $herecurr);
- }
-
# check for multiple semicolons
if ($line =~ /;\s*;\s*$/) {
if (WARN("ONE_SEMICOLON",
_
next prev parent reply other threads:[~2014-03-22 17:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 16:18 [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL Fabian Frederick
2014-03-21 20:00 ` Andrew Morton
2014-03-21 23:21 ` Fabian Frederick
2014-03-21 23:27 ` Andrew Morton
2014-03-22 17:03 ` tytso
2014-03-22 17:15 ` Andrew Morton
2014-03-22 17:26 ` tytso
2014-03-22 17:32 ` tytso
2014-03-22 17:55 ` Andrew Morton [this message]
2014-03-22 18:12 ` tytso
2014-03-22 18:56 ` Joe Perches
2014-03-26 1:07 ` David Rientjes
2014-03-22 19:24 ` Dave Jones
2014-03-26 1:06 ` David Rientjes
2014-03-26 6:19 ` tytso
2014-03-26 6:32 ` Andrew Morton
2014-03-26 13:29 ` tytso
2014-03-27 4:38 ` David Rientjes
2014-03-22 21:13 ` Fabian Frederick
2014-03-24 14:00 ` One Thousand Gnomes
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=20140322105524.7baec73a.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=fabf@skynet.be \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-devel@vger.kernel.org \
--cc=rientjes@google.com \
--cc=tytso@mit.edu \
/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.