Re: [PATCH v2 0/7] fs/9p: Reuse inode based on path (in addition to qid)

[Christian Schoenebeck <linux_oss@crudebyte.com>]

On Monday, September 15, 2025 2:53:14 PM CEST Dominique Martinet wrote:
[...]
> > 1. The qid is 9pfs internal data, and we may need extra API for 9pfs to
> > 
> >    expose this to Landlock.  On 64bit, this is easy as it's just the inode
> >    number (offset by 2), which we can already get from the struct inode.
> >    But perhaps on 32bit we need a way to expose the full 64bit server-sent
> >    qid to Landlock (or other kernel subsystems), if we're going to do
> >    this.
> 
> I'm not sure how much effort we want to spend on 32bit: as far as I
> know, if we have inode number collision on 32 bit we're already in
> trouble (tools like tar will consider such files to be hardlink of each
> other and happily skip reading data, producing corrupted archives);
> this is not a happy state but I don't know how to do better in any
> reasonable way, so we can probably keep a similar limitation for 32bit
> and use inode number directly...

I agree, on 32-bit the game is lost.

One way that would come to my mind though: exposing the full qid path as xattr 
on 32-bit, e.g. via "system.9pfs_qid" or something like that.

> > 2. Even though qids are supposed to be unique across the lifetime of a
> > 
> >    filesystem (including deleted files), this is not the case even for
> >    QEMU in multidevs=remap mode, when running on ext4, as tested on QEMU
> >    10.1.0.
> 
> I'm not familiar with the qid remap implementation in qemu, but I'm
> curious in what case you hit that.
> Deleting and recreating files? Or as you seem to say below the 'qid' is
> "freed" when fd is closed qemu-side and re-used by later open of other
> files?

The inode remap algorithm in QEMU's 9p server was designed to prevent inode 
number collisions of equally numbered inodes of *different* *devices* on host, 
exposed to guest via the same 9p mount (which appears as only one 9pfs device 
on guest). Basis for this however is still the underlying filesystem's inode 
number on host.

So yes, ext4 re-uses inode numbers of deleted files, and when that happens, a 
new file appears with the same qid path as the previously deleted file with 
QEMU.

/Christian