All of lore.kernel.org
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Fabian Frederick <fabf@skynet.be>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	reiserfs-devel@vger.kernel.org
Subject: Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete  __GFP_NOFAIL
Date: Sat, 22 Mar 2014 13:03:22 -0400	[thread overview]
Message-ID: <20140322170322.GA23583@thunk.org> (raw)
In-Reply-To: <20140321130055.c0ea32946f3543cd7f6bedd6@linux-foundation.org>

On Fri, Mar 21, 2014 at 01:00:55PM -0700, Andrew Morton wrote:
> 
> The whole point of __GFP_NOFAIL is to centralise this
> wait-for-memory-for-ever operation.  So it is implemented in a common
> (core) place and so that we can easily locate these problematic
> callers.
> 
> is exactly wrong.  Yes, we'd like __GFP_NOFAIL to go away, but it
> cannot go away until buggy callsites such as this one are *fixed*. 
> Removing the __GFP_NOFAIL usage simply hides the buggy code from casual
> searchers.

The change to jbd2 was made in July 2010, back when the "we must
exterminate GFP_NOFAIL at all costs" brigade was in high gear, and the
folks claiming that GFP_FAIL *would* go away, come hell or high water,
was a bit more emphatic.

I'll note that since 2011, there has been precious little movement on
removing the final few callers of GFP_NOFAIL, and we still have a bit
under two dozen of them, including a new one in fs/buffer.c that was
added in 2013.

In any case, __GFP_NOFAIL is in the code comments, so a casual
searcher would find it pretty quickly with a "git grep".

	       	       	      	      	   - Ted

  parent reply	other threads:[~2014-03-22 17:03 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 [this message]
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
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=20140322170322.GA23583@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=fabf@skynet.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-devel@vger.kernel.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 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.