From: "Maxim V. Patlasov" <mpatlasov@parallels.com>
To: Brian Foster <bfoster@redhat.com>
Cc: <miklos@szeredi.hu>, <dev@parallels.com>, <xemul@parallels.com>,
<fuse-devel@lists.sourceforge.net>,
<linux-kernel@vger.kernel.org>, <devel@openvz.org>,
<anand.avati@gmail.com>
Subject: Re: [PATCH 3/5] fuse: wait for end of IO on release
Date: Tue, 15 Jan 2013 18:04:12 +0400 [thread overview]
Message-ID: <50F561DC.6000700@parallels.com> (raw)
In-Reply-To: <50E49A06.4060901@redhat.com>
Hi Brian,
01/03/2013 12:35 AM, Brian Foster пишет:
> On 12/20/2012 07:31 AM, Maxim Patlasov wrote:
>> There are two types of I/O activity that can be "in progress" at the time
>> of fuse_release() execution: asynchronous read-ahead and write-back. The
>> patch ensures that they are completed before fuse_release_common sends
>> FUSE_RELEASE to userspace.
>>
>> So far as fuse_release() waits for end of async I/O, its callbacks
>> (fuse_readpages_end and fuse_writepage_finish) calling fuse_file_put cannot
>> be the last holders of fuse file anymore. To emphasize the fact, the patch
>> replaces fuse_file_put with __fuse_file_put there.
>>
>> Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
>> ---
>> fs/fuse/file.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
>> 1 files changed, 52 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
>> index 4f23134..aed9be2 100644
>> --- a/fs/fuse/file.c
>> +++ b/fs/fuse/file.c
>> @@ -137,6 +137,12 @@ static void fuse_file_put(struct fuse_file *ff, bool sync)
>> }
>> }
>>
>> +static void __fuse_file_put(struct fuse_file *ff)
>> +{
>> + if (atomic_dec_and_test(&ff->count))
>> + BUG();
>> +}
>> +
> I think a comment in or before this function to explain the reasoning
> for the BUG would be helpful.
>
>> int fuse_do_open(struct fuse_conn *fc, u64 nodeid, struct file *file,
>> bool isdir)
>> {
>> @@ -260,7 +266,12 @@ void fuse_release_common(struct file *file, int opcode)
>> * Make the release synchronous if this is a fuseblk mount,
>> * synchronous RELEASE is allowed (and desirable) in this case
>> * because the server can be trusted not to screw up.
>> + *
>> + * We might wait for them (asynchronous READ or WRITE requests), so:
>> */
>> + if (ff->fc->close_wait)
>> + BUG_ON(atomic_read(&ff->count) != 1);
>> +
> It might be cleaner to pull the new part of the comment and the BUG_ON()
> check to before the existing comment and fuse_file_put (e.g., create a
> new comment).
>
>> fuse_file_put(ff, ff->fc->destroy_req != NULL);
>> }
>>
>> @@ -271,6 +282,31 @@ static int fuse_open(struct inode *inode, struct file *file)
>>
>> static int fuse_release(struct inode *inode, struct file *file)
>> {
>> + struct fuse_file *ff = file->private_data;
>> +
>> + if (ff->fc->close_wait) {
>> + struct fuse_inode *fi = get_fuse_inode(inode);
>> +
>> + /*
>> + * Must remove file from write list. Otherwise it is possible
>> + * this file will get more writeback from another files
>> + * rerouted via write_files.
>> + */
>> + spin_lock(&ff->fc->lock);
>> + list_del_init(&ff->write_entry);
>> + spin_unlock(&ff->fc->lock);
>> +
>> + wait_event(fi->page_waitq, atomic_read(&ff->count) == 1);
>> +
>> + /*
>> + * Wait for threads just released ff to leave their critical
>> + * sections. Taking spinlock is the first thing
>> + * fuse_release_common does, so that this is unnecessary, but
>> + * it is still good to emphasize right here, that we need this.
>> + */
>> + spin_unlock_wait(&ff->fc->lock);
> I'm all for clarity, but if the wait is unnecessary, perhaps just leave
> the comment..? Just my .02.
>
> Aside from the few nits here, the set looks pretty good to me.
Thanks for review, the suggestions look reasonable. I'll resend
corrected patch soon.
Maxim
next prev parent reply other threads:[~2013-01-15 14:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-20 12:30 [PATCH 0/5] fuse: close file synchronously Maxim Patlasov
2012-12-20 12:31 ` [PATCH 1/5] fuse: add close_wait flag to fuse_conn Maxim Patlasov
2012-12-20 12:31 ` [PATCH 2/5] fuse: cosmetic rework of fuse_send_readpages Maxim Patlasov
2012-12-20 12:31 ` [PATCH 3/5] fuse: wait for end of IO on release Maxim Patlasov
2013-01-02 20:35 ` Brian Foster
2013-01-15 14:04 ` Maxim V. Patlasov [this message]
2013-01-15 15:02 ` [PATCH] fuse: wait for end of IO on release (v2) Maxim Patlasov
2012-12-20 12:32 ` [PATCH 4/5] fuse: enable close_wait feature Maxim Patlasov
2013-01-15 15:07 ` [PATCH] fuse: enable close_wait feature (v2) Maxim Patlasov
2012-12-20 12:32 ` [PATCH 5/5] fuse: fix synchronous case of fuse_file_put() Maxim Patlasov
2013-04-11 11:21 ` [fuse-devel] [PATCH 0/5] fuse: close file synchronously Maxim V. Patlasov
2013-04-15 15:08 ` Miklos Szeredi
2013-04-15 15:30 ` Miklos Szeredi
2013-04-15 18:17 ` Al Viro
2013-04-16 9:09 ` Miklos Szeredi
2013-04-17 20:53 ` Miklos Szeredi
2013-04-18 3:25 ` Maxim Patlasov
2013-04-16 18:13 ` Maxim Patlasov
2014-06-06 13:27 [PATCH 0/5] fuse: close file synchronously (v2) Maxim Patlasov
2014-06-06 13:29 ` [PATCH 3/5] fuse: wait for end of IO on release Maxim Patlasov
2014-09-25 12:05 [PATCH 0/5] fuse: handle release synchronously (v4) Maxim Patlasov
2014-09-25 12:06 ` [PATCH 3/5] fuse: wait for end of IO on release Maxim Patlasov
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=50F561DC.6000700@parallels.com \
--to=mpatlasov@parallels.com \
--cc=anand.avati@gmail.com \
--cc=bfoster@redhat.com \
--cc=dev@parallels.com \
--cc=devel@openvz.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=xemul@parallels.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).