Btrfs devel - Mar 2012 - [RFC PATCH 1/2] vfs: add an interface to do some preparation for umount

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.

Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
 fs/namespace.c     |    2 ++
 include/linux/fs.h |    1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index e608199..f5c1cce 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1173,6 +1173,8 @@ static int do_umount(struct mount *mnt, int flags)
 	}
 	br_write_unlock(vfsmount_lock);
 	up_write(&namespace_sem);
+	if (!retval && sb->s_op->umount_prepare)
+		sb->s_op->umount_prepare(sb);
 	release_mounts(&umount_list);
 	return retval;
 }
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 69cd5bb..6b9657c 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1686,6 +1686,7 @@ struct super_operations {
 	int (*statfs) (struct dentry *, struct kstatfs *);
 	int (*remount_fs) (struct super_block *, int *, char *);
 	void (*umount_begin) (struct super_block *);
+	void (*umount_prepare) (struct super_block *);
 
 	int (*show_options)(struct seq_file *, struct dentry *);
 	int (*show_devname)(struct seq_file *, struct dentry *);
-- 
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
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