Re: Kernel 5.4 breaks fuse 2.X nonempty mount option

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

 



On Sun, Jun 21, 2020 at 9:33 PM Stefan Priebe - Profihost AG
<s.priebe@xxxxxxxxxxxx> wrote:
>
> Hi David,
>
> i did a git bisect and the breaking commit is:
>
> commit c30da2e981a703c6b1d49911511f7ade8dac20be
> Author: David Howells <dhowells@xxxxxxxxxx>
> Date:   Mon Mar 25 16:38:31 2019 +0000
>
>     fuse: convert to use the new mount API
>
>     Convert the fuse filesystem to the new internal mount API as the old
>     one will be obsoleted and removed.  This allows greater flexibility in
>     communication of mount parameters between userspace, the VFS and the
>     filesystem.
>
>     See Documentation/filesystems/mount_api.txt for more information.
>
>     Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
>     Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
>     Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxxxxx>
>
> most probably due to the following diffences:
>
>
> old default:
>                default:
> -                       return 0;
>
>
> new default:
> +       default:
> +               return -EINVAL;
>
>
> it seems the old API silently did ignore unknown parameters while the
> new one fails with EINVAL.

v4.19 has this:

static int parse_fuse_opt(char *opt, struct fuse_mount_data *d, int is_bdev,
                          struct user_namespace *user_ns)
{
[...]
        while ((p = strsep(&opt, ",")) != NULL) {
[...]
                token = match_token(p, tokens, args);
                switch (token) {
[...]
                default:
                        return 0;

and

static int fuse_fill_super(struct super_block *sb, void *data, int silent)
{
[...]
        err = -EINVAL;
        if (sb->s_flags & SB_MANDLOCK)
                goto err;

        sb->s_flags &= ~(SB_NOSEC | SB_I_VERSION);

        if (!parse_fuse_opt(data, &d, is_bdev, sb->s_user_ns))
                goto err;
[...]
 err:
        return err;
}

That looks like it returns -EINVAL for unknown options.  Can you
perform a "strace" on the old and the new kernel to see what the
difference is?

BTW, the hard rule is: userspace regressions caused by kernel changes
must be fixed.  It's just not clear where exactly this is coming from.

Thanks,
Miklos



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux