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

[Mickaël Salaün]

On Mon, Sep 15, 2025 at 04:10:07PM +0200, Christian Schoenebeck wrote:
> 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.

Another way to always deal with 64-bit values, even on 32-bit
architectures, would be to implement inode->i_op->getattr(), but that
could have side effects for 9p users expecting the current behavior.

> 
> > > 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
> 
> 
>