On Sat 22-01-11 22:29:01, Joel Becker wrote:

On Sun, Jan 23, 2011 at 12:40:49AM -0500, Ted Ts'o wrote:

quoted

On Sat, Jan 22, 2011 at 07:32:44PM -0800, Manish Katiyar wrote:

quoted

 Hi Jan,

This is the follow up from https://lkml.org/lkml/2011/1/17/154
Following patches make jbd2 to use GFP_KERNEL for transaction
allocation if the caller can handle the errors. Following is the list
of functions that I updated to pass the new flag. Also below is the
list of functions which still have the old behavior and pass the old
flags (either because they can't deal with errors, or I wasn't too
sure so I did conservatively). Appreciate your feedback. The other
callers of jbd2_journal_start() are from ocfs2, they still pass the
old flag.

Hmm, I wonder if it would be better to use

jbd2_journal_start(...)

and

jbd2_journal_start_nofail(...)

	This API is markedly better to read.  Btw, does _nofail() mean no
possible failures, or just no memory errors?  If it is no failures, I'd
love to see the function become void.

  jbd2_journal_start can always fail e.g. because the journal is aborted.
So it really just means no memory failures...

quoted

The tradeoff is that long-term, the code is more readable (as opposed
to having people look up what a random "true" or "false" value means).
But short-term, while it will make the patch smaller, it also makes
the patch harder audit, since we need to look at all of the places
where we _haven't_ made a change to make sure those call sites can
tolerate an error return.

	I think we should start with jbd2_journal_start_can_fail() or
something like it, and change it back to jbd2_journal_start() in the
next window.  It's a silly name, but it catches exactly what you are
worried about.

  Yes, I think this would be nice for auditting (but for that matter
current interface with additional argument isn't bad either and we can
just do the rename to _nofail in the final patch...).

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR