Re: [PATCH v3] fuse: back uncached readdir buffers with pages

[Matt Ochs]

> On May 19, 2026, at 05:04, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> 
> On Tue, 19 May 2026 at 02:47, Matthew R. Ochs <mochs@xxxxxxxxxx> wrote:
> 
>> This was observed with a 64K-page guest on a 4K-page host, using an
>> overlayfs mount whose lower directory is on virtiofs. Reading a merged
>> directory through overlayfs failed with:
>> 
>>  ls: reading directory '<path>': Cannot allocate memory
> 
> IDGI, the patch makes FUSE_READDIR supply an array of folios.
> Virtiofs shouldn't need to allocate a large argbuf after that.
> 
> What am I missing?

You're right. After switching READDIR to out_pages, the large READDIR
reply payload should no longer be copied through req->argbuf. My commit
message conflated that with the separate request-size issue.

What I saw while testing the page-backed version was that the READDIR
size was still derived from fc->max_pages using the guest PAGE_SIZE. On
the failing 4K host / 64K guest setup that produced:

  PAGE_SIZE=65536 max_pages=124 max_read=UINT_MAX max_write=1048576
  bufsize=8126464 nr_pages=124

With out_pages but without the byte-size cap, fuse_simple_request()
still returned -ENOMEM. Capping the request to 1048576 bytes / 16 pages
made the same test pass.

So the out_pages change fixes the large reply-payload argbuf problem.
The fc->max_read/fc->max_write cap is addressing the separate issue that
fc->max_pages is only a page-count limit and can translate to an
oversized READDIR byte count when the client PAGE_SIZE differs.

I can rework the commit message to make that distinction clear.


-matt