Re: [patch 6/6] jbd2: remove dependency on __GFP_NOFAIL

[Ted Ts'o <tytso@mit.edu>]

On Tue, Jul 20, 2010 at 07:45:10PM -0700, David Rientjes wrote:
> The kzalloc() in start_this_handle() is failable, so remove __GFP_NOFAIL
> from its mask.

Unfortunately, while there is error handling in start_this_handle(),
there isn't in all of the callers of start_this_handle(), which is why
the __GFP_NOFAIL is there.  At the moment, if we get an ENOMEM in the
delayed writeback code paths, for example, it's a disaster; user data
can get lost, as a result.

I could add retry code in the places where we really can't fail, and
reflect the change back up to the userspace code everywhere else, but
that will take a while to do, and even then it means that any VFS
syscall (chmod, unlink, rmdir, mkdir, read, close, etc.) would now
potentially return ENOMEM.  And we know how often application
programmers do error checking....

But until we fix up all of the callers of jbd2_journal_start() and
jbd2_journal_restart(), I'd prefer keep this __GFP_NOFAIL in place,
thanks.

						- Ted

P.S.  There may also be some places where we haven't taken locks yet,
and so it might be safe in a few locations to omit the GFP_NOFS flag.
That would mean adding a new version of jbd2_journal_start() which can
take a gfp_mask, but the net result would be a file system that would
be a little bit more of a "good citizen" as far as allowing memory
reclaim.  I am worried about reflecting ENOMEM errors back up to
userspace, though, since I'm painfully aware of how much crappy
userspace code is out there.  What might be nice is a
"__GFP_RETRY_HARDER" which is weaker form of __GFP_NOFAIL...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>