Re: recap of 9p problems in 6.9

["Eric Van Hensbergen" <eric.vanhensbergen@linux.dev>]

April 7, 2024 at 11:17 PM, "Dominique Martinet" <asmadeus@codewreck.org> wrote:
> 
> Hi Eric (& anyone else reading on the list),
> 
> * open / unlink / fstat|ftruncate etc fail
> 
> https://lkml.kernel.org/r/E7D462A2-EE93-4A57-9F15-8565EE1567F3@linux.dev
> 
> I didn't confirm yet but I think it's a new bug? maybe the 'fix dups 
> even in uncached mode' patch dropping v9fs_drop_inode(); that's easy
> enough to test just a new bug so didn't look yet

I was thinking about this one a bit more -- this smells like the old anonymous file bug -- but I started thinking a bit about it.  fstat ultimately leads to a getattr -- in 9p classic those happen against unopen files only so it'll go looking for a transient fid which won't be there if we've unlinked.  Its possible that in this scenario we should return the "cached" information for the file (which we have in the inode) if we can't find the fid via a walk (which we won't if its unlinked).

Not sure if ftruncate is that same problem or different - right now the truncate code seems to be in setattr.  Need to do a bit of tracing to see if that's the path we are in.  There was a truncate bug spotted in legacy 9p, but I think that's something different.

So...is this a new bug?  Maybe.  I thought I might have removed the "failsafe" fid lookup of open files off of an inode -- but I see that this is still there, but it only uses it if the inode is still linked to the d_entry and we've just unlinked it.  I can see in the VFS code path its pulling the inode from the path (d_backing_inode(path->dentry) -- so maybe we just do the same thing for getattr if we fail to lookup the fid.


It would be really nice if we could just get to the file structure, but in both of these cases that seems to be "lost along the way" in the VFS call-chain.

      -eric