Re: VFS regression with 9pfs ("Lookup would have caused loop")

[Linux regression tracking (Thorsten Leemhuis)]

On 23.10.24 01:00, Dominique Martinet wrote:
> Will Deacon wrote on Tue, Oct 22, 2024 at 04:01:49PM +0100:
>
> [...]

Dominique, thx for taking the time to take care of this.

> I've also confirmed reverting the 4 commits listed by Will do fix both
> behaviors (along with a fscache warning when hitting the duplicate inode
> file, but that's expected):
>         724a08450f74 "fs/9p: simplify iget to remove unnecessary paths"
>         11763a8598f8 "fs/9p: fix uaf in in v9fs_stat2inode_dotl"
>         10211b4a23cf "fs/9p: remove redundant pointer v9ses"
>         d05dcfdf5e16 " fs/9p: mitigate inode collisions"
> [...]
> I think that's the sane thing to do, let's first go back to something
> that works and we can try again if/when someone has time - [...]
> 
> Thorsten, is there a preferred way reverts should be done?
> In this case it'd probably make sense to squash the 4 reverts in a
> single megarevert? At the very least getting anywhere in the middle with
> the uaf isn't something one would want... And they all made it in 6.9
> together so there's no benefit in splitting them for backport either.

Will might be the better person to ask, but since you asked me: I think
I've see a "megarevert" recently from the corner of my eye, but that
made me go "huh, that is unusual". My perception might wrong and in some
situations they might be a good idea. Not sure if this is one to to the
UAF. But that would only be relevant during a bisection or for everyone
stupid enough to backport only some of the reverts (if I understood you
right). I guess a proper patch description and a common Fixes: tag for
all four should prevent that.

Ciao, THorsten