Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL

From: Dave Jones
Date: Sat Mar 22 2014 - 15:24:57 EST

On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
> On Sat, 22 Mar 2014 13:32:07 -0400 tytso@xxxxxxx wrote:
>
> > On Sat, Mar 22, 2014 at 01:26:06PM -0400, tytso@xxxxxxx 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?

I wonder if some of that thinking came from this..

commit dab48dab37d2770824420d1e01730a107fade1aa
Author: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Date: Tue Jun 16 15:32:37 2009 -0700

page-allocator: warn if __GFP_NOFAIL is used for a large allocation

__GFP_NOFAIL is a bad fiction. Allocations _can_ fail, and callers should
detect and suitably handle this (and not by lamely moving the infinite
loop up to the caller level either).


Perhaps some of the commentary in that changeset should be updated too.
Linus changed it from single page to > order 1 in 4923abf9f1a4c1864af438a57c1f3686548230e9
but there's still this..

+ * __GFP_NOFAIL is not to be used in new code.
+ *
+ * All __GFP_NOFAIL callers should be fixed so that they
+ * properly detect and handle allocation failures.


Additionally, I don't recall seeing that warn_on trigger in a while.
I have vague memories that e1000e used to step on it from time to time, but
maybe that got fixed.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/