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

[Christian Schoenebeck <linux_oss@crudebyte.com>]

On Tuesday, September 16, 2025 4:01:40 PM CEST Tingmao Wang wrote:
> On 9/16/25 14:35, Dominique Martinet wrote:
> > Tingmao Wang wrote on Tue, Sep 16, 2025 at 01:44:27PM +0100:
> >> [...]
> >> 
> >> Note that in discussion with Mickaël (maintainer of Landlock) he
> >> indicated
> >> that he would be comfortable for Landlock to track a qid, instead of
> >> holding a inode, specifically for 9pfs.
> > 
> > Yes, I saw that, but what you pointed out about qid reuse make me
> > somewhat uncomfortable with that direction -- you could allow a
> > directory, delete it, create a new one somewhere else and if the
> > underlying fs reuse the same inode number the rule would allow an
> > intended directory instead so I'd rather not rely on qid for this
> > either.
> > But if you think that's not a problem in practice (because e.g. landlock
> > would somehow detect the dir got deleted or another good reason it's not
> > a problem) then I agree it's probably the simplest way forward
> > implementation-wise.
> 
> Sorry, I forgot to add that this idea would also involve Landlock holding
> a reference to the fid (or dentry, but that's problematic due to breaking
> unmount unless we can have a new hook) to keep the file open on the host
> side so that the qid won't be reused (ignoring collisions caused by
> different filesystems mounted under one 9pfs export when multidev mapping
> is not enabled)

I see that you are proposing an option for your proposed qid based re-using of 
dentries. I don't think it should be on by default though, considering what we 
already discussed (e.g. inodes recycled by ext4, but also not all 9p servers 
handling inode collisions).

> (There's the separate issue of QEMU not seemingly keeping a directory open
> on the host when the guest has a fid to it tho.  I checked that if the dir
> is renamed on the host side, any process in the guest that has a fd to it
> (checked via cd in a shell) will not be able to use that fd to read it
> anymore.  This also means that another directory might be created with the
> same qid.path)

For all open FIDs QEMU retains a descriptor to the file/directory.

Which 9p message do you see sent to server, Trename or Trenameat?

Does this always happen to you or just sometimes, i.e. under heavy load? 
Because even though QEMU retains descriptors of open FIDs; when the QEMU 
process approaches host system's max. allowed number of open file descriptors 
then v9fs_reclaim_fd() [hw/9pfs/9p.c] is called, which closes some descriptors 
of older FIDs to (at least) keep the QEMU process alive.

BTW: to prevent these descriptor reclaims to happen too often, I plan to do 
what many other files servers do: asking the host system on process start to 
increase the max. number of file descriptors.

/Christian