From: Tao Ma <tm@tao.ma>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
Nick Piggin <npiggin@kernel.dk>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
Chris Mason <chris.mason@oracle.com>
Subject: Re: [PATCH] VFS: call synchronize_rcu after kill_sb.
Date: Wed, 09 Feb 2011 09:49:15 +0800 [thread overview]
Message-ID: <4D51F29B.8060304@tao.ma> (raw)
In-Reply-To: <4D517C98.7060000@panasas.com>
On 02/09/2011 01:25 AM, Boaz Harrosh wrote:
> On 02/08/2011 06:57 PM, Aneesh Kumar K. V wrote:
>
>> On Mon, 07 Feb 2011 15:14:40 +0200, Boaz Harrosh<bharrosh@panasas.com> wrote:
>>
>>> On 02/05/2011 11:01 AM, Tao Ma wrote:
>>>
>>>> From: Tao Ma<boyu.mt@taobao.com>
>>>>
>>>> In fa0d7e3, we use rcu free inode instead of freeing the inode
>>>> directly. It causes a problem when we rmmod immediately after
>>>> we umount the volume[1].
>>>>
>>>> So we need to call synchronize_rcu after we kill_sb so that
>>>> the inode is freed before we do rmmod. The idea is inspired
>>>> by Chris Mason[2]. I tested with ext4 by umount+rmmod and it
>>>> doesn't show any error by now.
>>>>
>>>> 1. http://marc.info/?l=linux-fsdevel&m=129680863330185&w=2
>>>> 2. http://marc.info/?l=linux-fsdevel&m=129684698713709&w=2
>>>>
>>>> Cc: Nick Piggin<npiggin@kernel.dk>
>>>> Cc: Al Viro<viro@zeniv.linux.org.uk>
>>>> Cc: Chris Mason<chris.mason@oracle.com>
>>>> Cc: Boaz Harrosh<bharrosh@panasas.com>
>>>> Signed-off-by: Tao Ma<boyu.mt@taobao.com>
>>>> ---
>>>> fs/super.c | 7 +++++++
>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/fs/super.c b/fs/super.c
>>>> index 74e149e..315bce9 100644
>>>> --- a/fs/super.c
>>>> +++ b/fs/super.c
>>>> @@ -177,6 +177,13 @@ void deactivate_locked_super(struct super_block *s)
>>>> struct file_system_type *fs = s->s_type;
>>>> if (atomic_dec_and_test(&s->s_active)) {
>>>> fs->kill_sb(s);
>>>> + /*
>>>> + * We need to synchronize rcu here so that
>>>> + * the delayed rcu inode free can be executed
>>>> + * before we put_super.
>>>> + * https://bugzilla.kernel.org/show_bug.cgi?id=27652
>>>> + */
>>>> + synchronize_rcu();
>>>> put_filesystem(fs);
>>>> put_super(s);
>>>> } else {
>>>>
>>>
>>>
> <>
>
>> http://lwn.net/Articles/217484/ explains how to wait for rcu callback to finish
>>
>> -aneesh
>>
> Yes thanks Aneesh, rcu_barrier does the trick
> ---
> From: Boaz Harrosh<bharrosh@panasas.com>
>
> In fa0d7e3, we use rcu free inode instead of freeing the inode
> directly. It causes a problem when we rmmod immediately after
> we umount the volume[1].
>
> So we need to call rcu_barrier after we kill_sb so that
> the inode is freed before we do rmmod. The idea is inspired
> by Aneesh Kumar. rcu_barrier will wait for all callbacks
> to end before preceding. The original patch was done by
> Tao Ma, but synchronize_rcu() is not enough here.
>
> 1. http://marc.info/?l=linux-fsdevel&m=129680863330185&w=2
> 2. http://marc.info/?l=linux-fsdevel&m=129684698713709&w=2
>
> Cc: Nick Piggin<npiggin@kernel.dk>
> Cc: Al Viro<viro@zeniv.linux.org.uk>
> Cc: Chris Mason<chris.mason@oracle.com>
> Cc: Tao Ma<boyu.mt@taobao.com>
> Signed-off-by: Boaz Harrosh<bharrosh@panasas.com>
>
It works now in my ext4 test box. Thanks for your work.
Tested-by: Tao Ma <boyu.mt@taobao.com>
> ---
> git diff --stat -p -M fs/super.c
> fs/super.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/fs/super.c b/fs/super.c
> index 74e149e..5fd4ec9 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -177,6 +177,13 @@ void deactivate_locked_super(struct super_block *s)
> struct file_system_type *fs = s->s_type;
> if (atomic_dec_and_test(&s->s_active)) {
> fs->kill_sb(s);
> + /*
> + * We need to synchronize rcu here so that
> + * the delayed rcu inode free can be executed
> + * before we put_super.
> + * https://bugzilla.kernel.org/show_bug.cgi?id=27652
> + */
> + rcu_barrier();
> put_filesystem(fs);
> put_super(s);
> } else {
> --
> 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
>
next prev parent reply other threads:[~2011-02-09 1:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-05 9:01 [PATCH] VFS: call synchronize_rcu after kill_sb Tao Ma
2011-02-07 13:14 ` Boaz Harrosh
2011-02-08 16:57 ` Aneesh Kumar K. V
2011-02-08 17:25 ` Boaz Harrosh
2011-02-09 1:49 ` Tao Ma [this message]
2011-02-09 4:50 ` Christoph Hellwig
2011-02-09 8:26 ` [PATCH] VFS: call rcu_barrier " Boaz Harrosh
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=4D51F29B.8060304@tao.ma \
--to=tm@tao.ma \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bharrosh@panasas.com \
--cc=chris.mason@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=npiggin@kernel.dk \
--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.