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

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: <20240411092907.GA5494@redhat.com>
Date: Thu, 11 Apr 2024 11:29:07 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Eric Van Hensbergen <eric.vanhensbergen@...ux.dev>
Cc: v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org,
	kent.overstreet@...ux.dev
Subject: Re: [GIT PULL] fs/9p patches for 6.9 merge window

On 04/10, Eric Van Hensbergen wrote:
>
> April 10, 2024 at 12:20 PM, "Eric Van Hensbergen" <eric.vanhensbergen@...ux.dev> wrote:
> > April 8, 2024 at 9:14 AM, "Oleg Nesterov" <oleg@...hat.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.