linux-kernel - Re: [git pull] d_revalidate pile (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjKkZBM6w+Kc+nufJVdnBzzXwPiNdzWieN3c7dEq9bMaQ@mail.gmail.com>
Date: Thu, 30 Jan 2025 09:24:34 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>, Miklos Szeredi <mszeredi@...hat.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [git pull] d_revalidate pile (v2)

On Wed, 29 Jan 2025 at 20:37, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> ->d_revalidate() series, along with ->d_iname preliminary work.
> One trivial conflict in fs/afs/dir.c - afs_do_lookup_one() has lost
> one argument in mainline and switched another from dentry to qstr
> in this series.

Actually, I had a conflict in fs/fuse/dir.c, and it was less trivial.

The d_revalidate() change means that the stable name passed in might
come from the path lookup, which means that it isn't NUL-terminated.

So the code that did

        args->in_numargs = 1;
        args->in_args[0].size = name->len + 1;
        args->in_args[0].value = name->name;

in fuse_lookup_init() is no longer valid for revalidate, and  instead
you made it do the NUL termination as the next arg:

        args->in_numargs = 2;
        args->in_args[0].size = name->len;
        args->in_args[0].value = name->name;
        args->in_args[1].size = 1;
        args->in_args[1].value = "";

Fine, no problem. Except it clashes with commit 7ccd86ba3a48 ("fuse:
make args->in_args[0] to be always the header"), which made in_args[0]
be that empty case, and moved in_args[0] up to be arg[1].

So my resolution continues on that, and ends up with three in_args, like this:

        args->in_numargs = 3;
        fuse_set_zero_arg0(args);
        args->in_args[1].size = name->len;
        args->in_args[1].value = name->name;
        args->in_args[2].size = 1;
        args->in_args[2].value = "";

which looks straightforward enough, but I have not tested this AT ALL.

Miklos, can you please check and confirm that my resolution is ok? It
*looks* trivial, but there may be some reason why it causes issues. I
don't know the fuse code enough to really be able to tell what
implications this has (if there are people adding other args
afterwards, maybe we now have too many? Things like that)

               Linus