On Wed, 29 Jan 2025 at 20:37, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
