Re: [PATCH v5 0/9] btrfs: Fix freeze/sysfs deadlock in better method.

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: [PATCH v5 0/9] btrfs: Fix freeze/sysfs deadlock in better 
method.
From: Miao Xie <miaoxie@huawei.com>
To: <dsterba@suse.cz>, Qu Wenruo <quwenruo@cn.fujitsu.com>, 
<linux-btrfs@vger.kernel.org>
Date: 2015年01月31日 10:30
> On Fri, 30 Jan 2015 20:17:49 +0100, David Sterba wrote:
>> On Fri, Jan 30, 2015 at 05:20:45PM +0800, Qu Wenruo wrote:
>>> [Use VFS protect for sysfs change]
>>> The 6th patch will introduce a new help function sb_want_write() to
>>> claim write permission to a superblock.
>>> With this, we are able to do write protection like mnt_want_write() but
>>> only needs to ensure that the superblock is writeable.
>>> This also keeps the same synchronized behavior using ioctl, which will
>>> block on frozen fs until it is unfrozen.
>> You know what I think abuot the commit inside sysfs, but it looks better
>> to me now with the sb_* protections so I give it a go.
>> --
>> 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
>>
> I worried about the following case
>
> # fsfreeze btrfs
> # echo "new label" > btrfs_sysfs
> It should be hangup
Yes, same as "btrfs pro set <mnt> label "
>
>
> On the other terminal
> # umount btrfs
Oh, that's a problem.
It can be umounted, but....
>
>
> Because the 2nd echo command didn't increase mount reference, so umount
> would not know someone still blocked on the fs, it would not go back and
> return EBUSY like someone access the fs by common fs interface, it would
> deactive fs directly and then blocked on sysfs removal.
The btrfs module can't be removed, but not blocked. Just return -EBUSY.
So at least it won't cause annoying block problem.

Although hard for sysadmin to find pinpoint the real block reason, it is 
still resolvable, mount again and unfreeze
can resolve it.
But it never seems to be a reasonable behavior for me either.

Just as you mentioned, in sysfs, we only have sb, no vfsmount, so 
without huge VFS change(*),
we could either accept the wrong method, or drop all write sysfs support 
for transaction-invoking features.

*: Maybe we can add ref counts to sb, and umount syscall checks for the 
sb ref counts if the mount point
is the last vfsmount of it. I'm not sure whether it is worthy but it 
seems valid.

Thanks,
Qu

>
>
> Thanks
> Miao