All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>, Al Viro <viro@zeniv.linux.org.uk>,
	Josef Bacik <josef@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PULL REQUEST] ext3, jbd, ext2, and quota fixes for 3.1-rc1
Date: Tue, 26 Jul 2011 22:10:38 +0200	[thread overview]
Message-ID: <20110726201038.GE27993@quack.suse.cz> (raw)
In-Reply-To: <CA+55aFwYsdyE4KxFW70c_FfTb41m+EwchYvNJU-eUEw4usRkUw@mail.gmail.com>

On Tue 26-07-11 11:36:29, Linus Torvalds wrote:
> On Tue, Jul 26, 2011 at 11:14 AM, Jan Kara <jack@suse.cz> wrote:
> >
> >  could you please pull from
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs-2.6.git for_linus
> 
> Ok, this clashed with the fsync mutex pushdown, and the whole addition
> of fixed tracepoints.
> 
> Quite frankly, I think the fixed tracepoints are broken and make the
> code unreadable (why have them?) but I fixed it up.
> 
> Somebody should really double-check the resolve. That's especially
> true since the whole i_mutex thing is *also* rather dubious. The
> comment that moved that down says:
> 
> +       /*
> +        * Taking the mutex here just to keep consistent with how fsync was
> +        * called previously, however it looks like we don't need to take
> +        * i_mutex at all.
> +        */
> 
> but in fact it is *not* consistent with how fsync() used to be called,
> since we then drop the mutex *before* doing
> 
>     return ext3_force_commit(inode->i_sb);
> 
> for the should_journal_data case.
> 
> See commit 02c24a82187 ("fs: push i_mutex and filemap_write_and_wait
> down into ->fsync() handlers").
> 
> I resolved it with the mutex still dropped early (especially since the
> comment implies it may not matter at all), but quite frankly,
> everything I did around that resolve made me go "that code is just
> WRONG". Both wrt the tracepoints and wrt the i_mutex.
> 
> So I think my resolution is "correct" from a merge standpoint, but I
> think the code is total crap. I also wonder whether you can really do
> that
> 
>     J_ASSERT(ext3_journal_current_handle() == NULL);
> 
> without holding the i_mutex, so I moved that back down again.
> 
> So I *really* want people to take a look at that ext3_sync_file()
> function. Please?
  ext3_sync_file() really does not need i_mutex for anything. I've just
checked how you resolved the conflict and it looks nice. I'll queue a patch
which just removes i_mutex from that function altogether. Thanks for the
resolve.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>, Al Viro <viro@zeniv.linux.org.uk>,
	Josef Bacik <josef@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PULL REQUEST] ext3, jbd, ext2, and quota fixes for 3.1-rc1
Date: Tue, 26 Jul 2011 22:10:38 +0200	[thread overview]
Message-ID: <20110726201038.GE27993@quack.suse.cz> (raw)
In-Reply-To: <CA+55aFwYsdyE4KxFW70c_FfTb41m+EwchYvNJU-eUEw4usRkUw@mail.gmail.com>

On Tue 26-07-11 11:36:29, Linus Torvalds wrote:
> On Tue, Jul 26, 2011 at 11:14 AM, Jan Kara <jack@suse.cz> wrote:
> >
> >  could you please pull from
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs-2.6.git for_linus
> 
> Ok, this clashed with the fsync mutex pushdown, and the whole addition
> of fixed tracepoints.
> 
> Quite frankly, I think the fixed tracepoints are broken and make the
> code unreadable (why have them?) but I fixed it up.
> 
> Somebody should really double-check the resolve. That's especially
> true since the whole i_mutex thing is *also* rather dubious. The
> comment that moved that down says:
> 
> +       /*
> +        * Taking the mutex here just to keep consistent with how fsync was
> +        * called previously, however it looks like we don't need to take
> +        * i_mutex at all.
> +        */
> 
> but in fact it is *not* consistent with how fsync() used to be called,
> since we then drop the mutex *before* doing
> 
>     return ext3_force_commit(inode->i_sb);
> 
> for the should_journal_data case.
> 
> See commit 02c24a82187 ("fs: push i_mutex and filemap_write_and_wait
> down into ->fsync() handlers").
> 
> I resolved it with the mutex still dropped early (especially since the
> comment implies it may not matter at all), but quite frankly,
> everything I did around that resolve made me go "that code is just
> WRONG". Both wrt the tracepoints and wrt the i_mutex.
> 
> So I think my resolution is "correct" from a merge standpoint, but I
> think the code is total crap. I also wonder whether you can really do
> that
> 
>     J_ASSERT(ext3_journal_current_handle() == NULL);
> 
> without holding the i_mutex, so I moved that back down again.
> 
> So I *really* want people to take a look at that ext3_sync_file()
> function. Please?
  ext3_sync_file() really does not need i_mutex for anything. I've just
checked how you resolved the conflict and it looks nice. I'll queue a patch
which just removes i_mutex from that function altogether. Thanks for the
resolve.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2011-07-26 20:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-26 18:14 [PULL REQUEST] ext3, jbd, ext2, and quota fixes for 3.1-rc1 Jan Kara
2011-07-26 18:36 ` Linus Torvalds
2011-07-26 18:36   ` Linus Torvalds
2011-07-26 18:52   ` Al Viro
2011-07-26 18:59     ` Christoph Hellwig
2011-07-26 19:14       ` Linus Torvalds
2011-07-26 19:14         ` Linus Torvalds
2011-07-27  0:31         ` Ted Ts'o
2011-07-26 20:16     ` Jan Kara
2011-07-26 20:10   ` Jan Kara [this message]
2011-07-26 20:10     ` Jan Kara

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=20110726201038.GE27993@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=josef@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.