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

[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@zeniv.linux.org.uk>
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@zeniv.linux.org.uk>

: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@mail.gmail.com


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

-- 
MfG,

Michael Leun

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

[Al Viro]

On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote:

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

Sigh...  Check if the following fix works for your testcase:
diff --git a/fs/namespace.c b/fs/namespace.c
index b4f96a5..b68eef2d 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2284,12 +2284,11 @@ long do_mount(const char *dev_name, const char *dir_name,
 
 	retval = security_sb_mount(dev_name, &path,
 				   type_page, flags, data_page);
+	if (!retval && !may_mount())
+		retval = -EPERM;
 	if (retval)
 		goto dput_out;
 
-	if (!may_mount())
-		return -EPERM;
-
 	/* Default to relatime unless overriden */
 	if (!(flags & MS_NOATIME))
 		mnt_flags |= MNT_RELATIME;

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

[Michael Leun]

On Sat, 4 May 2013 16:52:14 +0100
Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote:
> 
> > After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9
> > that umount above works (not busy).
> 
> Sigh...  Check if the following fix works for your testcase:
> diff --git a/fs/namespace.c b/fs/namespace.c
> index b4f96a5..b68eef2d 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
[...]

Yup, that fixes it.

-- 
MfG,

Michael Leun

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

[Al Viro]

On Sat, May 04, 2013 at 08:02:40PM +0200, Michael Leun wrote:
> On Sat, 4 May 2013 16:52:14 +0100
> Al Viro <viro@ZenIV.linux.org.uk> wrote:
> 
> > On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote:
> > 
> > > After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9
> > > that umount above works (not busy).
> > 
> > Sigh...  Check if the following fix works for your testcase:
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index b4f96a5..b68eef2d 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> [...]
> 
> Yup, that fixes it.

OK, committed, will go to Linus today, with Cc: stable