linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Manish Katiyar <mkatiyar@gmail.com>
Cc: ext4 <linux-ext4@vger.kernel.org>
Subject: Re: Checking of NULL with __GFP_NOFAIL in kzalloc()
Date: Mon, 2 Mar 2009 08:44:11 -0500	[thread overview]
Message-ID: <20090302134411.GL6973@mit.edu> (raw)
In-Reply-To: <ea11fea30903012208k6992a019h9683b95379314b55@mail.gmail.com>

On Mon, Mar 02, 2009 at 11:38:53AM +0530, Manish Katiyar wrote:
> On Sun, Mar 1, 2009 at 11:35 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:
> > Hi,
> >
> > While going through jbd code, I was wondering why do we need to check
> > new_transaction for NULL, if we are passing __GFP_NOFAIL ?
> > Last code change around this code was when Ted converted kmalloc to
> > kzalloc, but since he also didn't remove it I am guessing there would
> > be some good reason for it. Can someone enlighten me ?
> 
> I didn't receive any response to this. So probably removing the NULL
> check is harmless. Or should I remove the __GFP_NOFAIL flag and keep
> the error handling ?

We don't want to remove __GFP_NOFAIL here since returning an error
would cause the filesystem to be marked as corrupted, and so it's
better to simply ask the memory allocator to retry until it can
succeed, which is what GFP_NOFAIL does.

This isn't an excuse for using GFP_NOFAIL in journal_init_common(),
though; that's an example of a use of __GFP_NOFAIL that should go
away.  (Basically, if that fails, the mount will fail; we should
printk an explanatory message since the mount system call return
EINVAL, but failing a mount due to not enough memory is reasonable.
Marking the filesystem as corrupted, and remounting the filesystem
read-only and/or panic'ing the system is not.)

						- Ted

      parent reply	other threads:[~2009-03-02 13:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-01  6:05 Checking of NULL with __GFP_NOFAIL in kzalloc() Manish Katiyar
2009-03-02  6:08 ` Manish Katiyar
2009-03-02  7:35   ` Andreas Dilger
2009-03-02  8:15     ` Manish Katiyar
2009-03-02 13:44   ` Theodore Tso [this message]

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=20090302134411.GL6973@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mkatiyar@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).