From: Miao Xie <miaox@cn.fujitsu.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Chris Mason <chris.mason@oracle.com>,
Linux Fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC PATCH 1/2] vfs: add an interface to do some preparation for umount
Date: Thu, 22 Mar 2012 13:07:19 +0800 [thread overview]
Message-ID: <4F6AB387.5010800@cn.fujitsu.com> (raw)
In-Reply-To: <20120322034109.GU6589@ZenIV.linux.org.uk>
On Thu, 22 Mar 2012 03:41:09 +0000, Al Viro wrote:
> On Thu, Mar 22, 2012 at 11:13:15AM +0800, Miao Xie wrote:
>> Some file systems can do some works in the background by kthreads, we'd
>> better stop those works before we umount the file system, or it is easy to
>> introduce some problems. So we add an interface that is used to do some
>> preparation for umount.
>
> NAK. First of all, fs might be in active use _after_ umount. man 8 umount,
> see umount -l there. Moreover, the same superblock may very well be mounted
> more than once, so umount of an individual mountpoint would better not do
> anything nasty to users of other ones.
>
> IOW, this is completely misguided - you are dealing with whatever problem it
> is at least two layers above the right one.
>
> 1) vfsmount may be detached from mount trees but remain in active use.
> 2) there may be many vfsmounts over given struct super_block.
>
> Doing things earlier than the final mntput() runs afoul of (1); doing
> them before the final deactivate_locked_super() runs afoul of (2).
>
> What the hell is that thread doing that needs ->s_umount for serialization
> and why is it doing that?
AFAIK, acquiring ->s_umount is to avoid the filesystem going from r/w to r/o.
This is patch is slapdash, I will find another way to deal with the bug we found.
Thanks for your review.
Miao
prev parent reply other threads:[~2012-03-22 5:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-22 3:13 [RFC PATCH 1/2] vfs: add an interface to do some preparation for umount Miao Xie
2012-03-22 3:41 ` Al Viro
2012-03-22 5:07 ` Miao Xie [this message]
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=4F6AB387.5010800@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.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.