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

[David Laight]

On Thu, 16 Apr 2026 11:31:02 +0900
Dominique Martinet <asmadeus@xxxxxxxxxxxxx> wrote:

> 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/496d10b9-40fe-4f81-8014-37497c37ff63@xxxxxxxxxxxxxxxx/  
> > (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 :/)

The problem is you need to get the correct offsets for the various calls.
So the directory entry sent to the user needs the correct offset the
server would use for the (next) directory entry.
If the latter aren't byte offsets into the buffer it probably impossible.

I have a vague recollection of some fs encoding 'directory block number'
and 'offset in directory block' into the 'file offset' for directory fd.

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

There might be something, file->offset needs protecting for readdir()
the same as for read() (but not pread()).
At least once (for some filesystem on some unix variant) readdir() would
have been pretty much the same as read().

	David

>