Re: [PATCH] 9p: use kvzalloc for readdir buffer

David Laight wrote on Wed, Apr 15, 2026 at 11:36:25AM +0100:
> > Perhaps what you describe can explain what I was seeing there:
> > https://lore.kernel.org/v9fs/[email protected]/
> (After seeking, getdents() returns stale cached entries instead of fetching from the new position.)
> 
> Absolutely.
> But the fix probably isn't trivial.
> The offset that you need for the seek isn't directly related to the number
> of bytes copied to the user buffer - which is what I suspect ftell() (or
> whatever gets used) returns.
> I think there is some mechanism for arbitrary directory offsets; but IIRC that
> requires the code put the 'file system offset for the next directory entry'
> somewhere in the directory entry.
> Such an offset would have to be one the remote system would understand.
> 
> A partial 'non-fix' would be to reject seeks to other than offset 0.


Thank you both for working on this and reviewing -- this is all
historical code that hasn't seen much love.


9p Treaddir sends an offset on each call, so I think it'd be fine to
invalidate buffer/remember whatever the client set in a custom llseek
function and send this to the server on readdir call, but I honestly
didn't give this any more thought than the past 2 mintes (I'm totally
swamped and can't keep up/didn't even notice the bug report this
december, sorry :/)
I think some filesystems only allow seeks to 0 already? So given there
is a precendent this might be fine, but I don't see the harm in allowing
custom offsets: the server needs to be able to deal with junk offsets in
read requests anyway, so it's not a problem for me if userspace can set
something invalid and get itself stuck on EINVAL or whatever.


As for locking the vfs takes the file's f_lock for seek, but there
doesn't seem to be anything in the readdir path that would do that, so I
guess it probably would blow up with parallel readdirs on the same fd,
and could use improving...

-- 
Dominique Martinet | Asmadeus