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
