Re: [GIT PULL] fs/9p patches for 6.9 merge window

[Oleg Nesterov <oleg@redhat.com>]

On 04/10, Eric Van Hensbergen wrote:
>
> April 10, 2024 at 12:20 PM, "Eric Van Hensbergen" <eric.vanhensbergen@linux.dev> wrote:
> > April 8, 2024 at 9:14 AM, "Oleg Nesterov" <oleg@redhat.com> wrote:
> > > Hello,
> > >  the commit 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths")
> > >  from this PR breaks my setup.
> >

> I think
> I've reproduced the problem, fundamentally, since you have two mount
> points you are exporting together. I believe we are getting an inode
> number collision which was being hidden by the "always create a new inode
> on lookup" inefficiency in v9fs_vfs_lookup.  You could probably verify
> that for me by stating the /home directory and the / directory on the
> server side of your setup.

Yes, yes,

	$ ls -ldi / /home
	2 dr-xr-xr-x. 18 root root 4096 Jan  4  2016 /
	2 drwxr-xr-x.  7 root root 4096 Dec 20  2022 /home

that is why I showed you the relevant parts of my /etc/fstab

> If qemu detects that this is a possibility it usually
> prints something: qemu-system-aarch64: warning: 9p: Multiple devices
> detected in same VirtFS export,

My qemu is quite old, it doesn't. But I tested this on another machine
and yes, the newer qemu does warn.

(annoyingly, I had to redirect stderr to the file to see this warning,
 it is cleared by the booting kernel otherwise).

> I can confirm that multidevs=remap in qemu does appear to avoid the
> problem,

Confirm!

I didn't know about this option (and again, my old qemu doesn't support
it), but everything seems to work just fine with the newer qemu and
multidevs=remap. Thanks!

So I think this regression is minor.

> now that i can
> reproduce the problem, I'm fairly certain I can get a patch together
> this week to test to see if it solves the regressions.

Thanks ;)

Oleg.