Received-SPF: pass (google.com: domain of linux-kernel+bounces-140178-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 11 Apr 2024 11:29:07 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Eric Van Hensbergen <eric.vanhensbergen@linux.dev>
Cc: v9fs@lists.linux.dev, linux-kernel@vger.kernel.org,
	kent.overstreet@linux.dev
Subject: Re: [GIT PULL] fs/9p patches for 6.9 merge window
Message-ID: <20240411092907.GA5494@redhat.com>
References: <ZfRkyxUf8TIgsYjA@1149290c588b>
 <20240408141436.GA17022@redhat.com>
 <74f117635037a82dc2fb2923993cf329b6939b7e@linux.dev>
 <e73a1e0c90ebce33c23f8f7746c23c1199f62a78@linux.dev>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e73a1e0c90ebce33c23f8f7746c23c1199f62a78@linux.dev>
User-Agent: Mutt/1.5.24 (2015-08-30)

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.