Re: VFS regression: commit aba809cf0944 breaks MNT_SHRINKABLE automounted partitions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Aug 30, 2014 at 7:01 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Aug 29, 2014 at 05:47:58PM -0400, Trond Myklebust wrote:
>
>> Note that the issue happens with NFSv4 or NFSv4.1 (not NFSv3).
>
> That's what I'd been using for testing.
>
>> Note that on my system, if I call 'umount' a second time after getting
>> the 'device is busy' error, then it succeeds. It looks as if the first
>> call to 'umount /mnt' causes the directory /mnt/export to clear,
>> causing the second 'umount /mnt' to succeeed (unless I try to access
>> /mnt/export again):
Just to be clear, it is what I saw as well. I did not get permanent
-EBUSY and I could umount /mnt if I run `umount /mnt` twice.

And I did not do git bisect. I had doubts in the code so I found the
specific commit to revert it and it worked. But if it is some other
commit in the middle, I could have missed it.

My theory to blame aba809cf0944 is that in
do_umount()->shrink_submounts()->umount_tree(), it transfers parent
mnt refcount (held by child mnt) to mnt_ex_mountpoint but that is put
_after_ do_umount() calls propagate_mount_busy(mnt, 2). So
propagate_mount_busy() would fail do_refcount_check(). Does it make
sense to you?

>
> Now, that smells like a different bug - see if commit ab8f2c from -next
> helps with that one.
>
I cherri-picked it and it still failed with -EBUSY.

Cheers,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux