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

[Andrew Morton]

On Wed, 26 Mar 2014 02:19:04 -0400 tytso@xxxxxxx wrote:

> On Tue, Mar 25, 2014 at 06:06:17PM -0700, David Rientjes wrote:
> > 
> > The point is not to add new callers and new code should handle NULL 
> > correctly, not that we should run around changing current users to just do 
> > infinite retries.  Checkpatch should have nothing to do with that.
> 
> My problem with this doctrinaire "there should never be any new users"
> is that sometiems there *are* worse things than infinite retries.  If
> the alternative is bringing the entire system down, or livelocking the
> entire system, or corrupting user data, __GFP_NOFAIL *is* the more
> appropriate option.

Well, there are always alternatives.  For example ext3 could
preallocate a single transaction_t and a single IO page and fall back
to synchronous page-at-a-time journal writes.  But I can totally see
that such things are unattractive: heaps of new code which is never
tested in real life.  The page allocator works so damn well that it
doesn't make sense to implement it.

> If you try to tell those of us outside of the mm layer, "thou shalt
> never use __GFP_NOFAIL in new code", and we have some new code where
> the alternative is worse, we can either open-code the loop, or have
> some mm hackers and/or checkpatch whine at us.
> 
> Andrew has declared that he'd prefer that we not open code the retry
> loop; if you want to disagree with Andrew, feel free to pursuade him
> otherwise.  If you want to tell me that I should accept user data
> corruption, I'm going to ignore you (and/or checkpatch).

Please use NOFAIL ;) The core page allocator will always be able to
implement this better than callers.
--
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/