[REGRESSION] bisected: 3.8 -> 3.9 cannot umount after using fuse

[Michael Leun]

Mount some filesystem, below that mountpoint as user mount some fuse fs
(tried that with sshfs and fuseiso, both same error), fusermount -u the
fuse fs, try to unmount the filesystem -> busy.

ml@lara:~> id -u
500
ml@lara:~> grep test /etc/fstab
/dev/vg1/test /mnt2 ext4acl,user_xattr,user,noauto   0 0 
ml@lara:~> mount /mnt2
ml@lara:~> cd /mnt2
ml@lara:/mnt2> ls -l
insgesamt 24
drwx------ 2 root root  16384  4. Mai 11:24 lost+found
drwxr-xr-x 2 root root   4096  4. Mai 11:44 test
drwxr-xr-x 2 ml   users  4096  4. Mai 11:25 xenia
ml@lara:/mnt2> sshfs xenia: xenia
Password: 
ml@lara:/mnt2> ls xenia/bla
xenia/bla
ml@lara:/mnt2> fusermount -u xenia
ml@lara:/mnt2> cd
ml@lara:~> umount /mnt2
umount: /mnt2: target is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
ml@lara:~> fuser -m /mnt2
ml@lara:~>

It does'nt matter if the mounting and unmounting of the /mnt2
filesystem is done as user or as root, same result.

This works in 3.8(.x). Bisecting yields

57eccb830f1cc93d4b506ba306d8dfa685e0c88f is the first bad commit
commit 57eccb830f1cc93d4b506ba306d8dfa685e0c88f
Author: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date:   Fri Feb 22 22:49:10 2013 -0500

    mount: consolidate permission checks
    
    ... and ask for global CAP_SYS_ADMIN only for superblock-level remounts
    
    Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>

:040000 040000 4e926c083f6ede645158f02714d73cdd3b233a05 584611744bad96544578259a6fa176577df0ebbd M      fs

After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9 that
umount above works (not busy).

I've seen that this patch also was identified as problem in relation
with user ns and module loading, see lkml

CAGXu5jLciqXcuhzDVPKPqA+mwv8e28zGAMScatzov3U07BuBaQ@xxxxxxxxxxxxxx


After fixing this upstream the fix should be an stabile candidate.

-- 
MfG,

Michael Leun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/