Re: [Ocfs2-devel] [PATCH 13/17] ocfs2: Update syncing aftersplicing to match generic version

From: Jan Kara
Date: Fri Aug 21 2009 - 10:30:56 EST


On Thu 20-08-09 18:36:17, Joel Becker wrote:
> On Wed, Aug 19, 2009 at 06:04:40PM +0200, Jan Kara wrote:
> > Update ocfs2 specific splicing code to use generic syncing helper.
> >
> > CC: Joel Becker <Joel.Becker@xxxxxxxxxx>
> > CC: ocfs2-devel@xxxxxxxxxxxxxx
> > Signed-off-by: Jan Kara <jack@xxxxxxx>
> > ---
> > fs/ocfs2/file.c | 27 ++++++---------------------
> > 1 files changed, 6 insertions(+), 21 deletions(-)
> >
> > diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
> > index 1c71f0a..bd7fdf8 100644
> > --- a/fs/ocfs2/file.c
> > +++ b/fs/ocfs2/file.c
> > @@ -1990,31 +1990,16 @@ static ssize_t ocfs2_file_splice_write(struct pipe_inode_info *pipe,
> >
> > if (ret > 0) {
> > unsigned long nr_pages;
> > + int err;
> >
> > - *ppos += ret;
> > nr_pages = (ret + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
> >
> > - /*
> > - * If file or inode is SYNC and we actually wrote some data,
> > - * sync it.
> > - */
> > - if (unlikely((out->f_flags & O_SYNC) || IS_SYNC(inode))) {
> > - int err;
> > -
> > - mutex_lock(&inode->i_mutex);
> > - err = ocfs2_rw_lock(inode, 1);
> > - if (err < 0) {
> > - mlog_errno(err);
> > - } else {
> > - err = generic_osync_inode(inode, mapping,
> > - OSYNC_METADATA|OSYNC_DATA);
> > - ocfs2_rw_unlock(inode, 1);
> > - }
> > - mutex_unlock(&inode->i_mutex);
> > + err = generic_write_sync(out, *ppos, ret);
> > + if (err)
> > + ret = err;
> > + else
> > + *ppos += ret;
>
> You've removed the rw_lock around the sync. Any reason why?
Ah, I should have written in the changelog: generic_write_sync() will
acquire i_mutex so to preserve lock ordering (i_mutex -> rw_lock) we cannot
hold it while calling generic_write_sync(). Furthermore, I didn't see point
for holding it while calling generic_write_sync() since we don't hold it
in fsync() path either.
I'll add something like this to the changelog.

Honza

--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/