All of lore.kernel.org
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: David Rientjes <rientjes@google.com>
Cc: Dave Jones <davej@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Fabian Frederick <fabf@skynet.be>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	reiserfs-devel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete  __GFP_NOFAIL
Date: Wed, 26 Mar 2014 02:19:04 -0400	[thread overview]
Message-ID: <20140326061904.GA4907@thunk.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1403251800320.21733@chino.kir.corp.google.com>

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.

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).

Regards,

						- Ted

  reply	other threads:[~2014-03-26  6:19 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
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 [this message]
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=20140326061904.GA4907@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=fabf@skynet.be \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=rientjes@google.com \
    /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.