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] [day] [month] [year] [list]

Message-ID: <20250131055625.GV1977892@ZenIV>
Date: Fri, 31 Jan 2025 05:56:25 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Miklos Szeredi <mszeredi@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] d_revalidate pile (v2)

On Thu, Jan 30, 2025 at 09:24:34AM -0800, Linus Torvalds wrote:
> 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 = "";

*nod*

My apologies - that did show up in -next (obviously), with the same
resolution you went for, everyone nodded and agreed that it was obviously
the right fix.  Should've mentioned that when updating pull request
message (that wasn't an issue in the first variant, since that had
been prior to fuse merge).  Sorry about missing that...