[lkml]   [2014]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL
On Wed, 26 Mar 2014 02:19:04 -0400 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.

 \ /
  Last update: 2014-03-26 08:01    [W:1.129 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site