When I look at what propagate_mount_busy is trying to do and I look at the code closely I discover there is a great disconnect between the two. In the ordinary non-propagation case propagate_mount_busy has been verifying that there are no submounts and that there are no extraneous references on the mount. For mounts that the unmount would propagate to propagate_mount_busy has been verifying that there are no extraneous references only if there are no submounts. Which is nonsense. Thefore rework the logic in propgate_mount_busy so that for each mount it examines it considers that mount busy if that mount has children or if there are extraneous references to that mount. While this check was incorrect we could leak mounts instead of simply failing umount. Cc: stable@xxxxxxxxxxxxxxx Fixes: a05964f3917c ("[PATCH] shared mounts handling: umount") Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> --- If you don't figure this fix is worth it after all of this time please let me know. This feels like the proper thing to do, and I don't expect it will break anyone to fix this. fs/pnode.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/fs/pnode.c b/fs/pnode.c index 06a793f4ae38..12fafa711114 100644 --- a/fs/pnode.c +++ b/fs/pnode.c @@ -344,7 +344,6 @@ int propagate_mount_busy(struct mount *mnt, int refcnt) { struct mount *m, *child; struct mount *parent = mnt->mnt_parent; - int ret = 0; if (mnt == parent) return do_refcount_check(mnt, refcnt); @@ -360,11 +359,13 @@ int propagate_mount_busy(struct mount *mnt, int refcnt) for (m = propagation_next(parent, parent); m; m = propagation_next(m, parent)) { child = __lookup_mnt_last(&m->mnt, mnt->mnt_mountpoint); - if (child && list_empty(&child->mnt_mounts) && - (ret = do_refcount_check(child, 1))) - break; + if (!child) + continue; + if (!list_empty(&child->mnt_mounts) || + do_refcount_check(child, 1)) + return 1; } - return ret; + return 0; } /* -- 2.10.1 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html