From: Matt Ochs <mochs@nvidia.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Bernd Schubert <bschubert@ddn.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] fuse: back uncached readdir buffers with pages
Date: Thu, 14 May 2026 21:35:41 +0000 [thread overview]
Message-ID: <486C7565-177D-4D6F-88DF-B7DFA3DA60F3@nvidia.com> (raw)
In-Reply-To: <D14CFB43-C7D8-4F3E-920B-E2A3B925E6B3@nvidia.com>
Hi Miklos,
> On Apr 30, 2026, at 14:24, Matt Ochs <mochs@nvidia.com> wrote:
>
>>
>> On Apr 29, 2026, at 02:27, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> On Wed, 29 Apr 2026 at 01:30, Matthew R. Ochs <mochs@nvidia.com> wrote:
>>
>>> The larger buffer is also currently supplied as a kvec output argument.
>>> For virtiofs, kvec arguments are copied through req->argbuf, which is
>>> allocated with kmalloc(..., GFP_ATOMIC). A large readdir buffer can
>>> therefore require a multi-megabyte contiguous atomic allocation and fail
>>> with -ENOMEM.
>>
>> Shouldn't this be max_read? Here "read" and "write" refer to
>> direction of I/O on the filesystem, not on the fuse device (see
>> fuse/file.c)
>
> Thanks, the read/write direction point makes sense.
>
> I tested changing the cap to fc->max_read only, but that reproduces the
> original virtiofs failure on the 4K-host/64K-guest setup. The runtime
> values for the failing READDIR are:
>
> PAGE_SIZE=65536
> fc->max_pages=124
> fc->max_read=4294967295
> fc->max_write=1048576
> max_bufsize=8126464
> nr_pages=124
>
> So for this virtiofs mount, fc->max_read is effectively unlimited, while
> virtiofsd advertises its 1 MiB MAX_BUFFER_SIZE through max_write and
> rejects READDIR sizes above that limit.
>
> Do you prefer handling this locally in fuse_readdir_uncached(), for
> example by capping the request with all available limits:
>
> min3_t(size_t, fc->max_pages << PAGE_SHIFT, fc->max_read, fc->max_write)
>
> Or should virtiofs/FUSE instead make fc->max_read reflect this byte-sized
> buffer limit before readdir uses it?
>
> I will address the other cleanup comments in v3: drop the cast, keep the
> clamp-style sizing, use release_pages(), and remove the nomem double jump.
>
Checking in if you have a preference on how this is handled?
-matt
next prev parent reply other threads:[~2026-05-14 21:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 23:29 [PATCH v2] fuse: back uncached readdir buffers with pages Matthew R. Ochs
2026-04-29 7:27 ` Miklos Szeredi
2026-04-30 19:24 ` Matt Ochs
2026-05-14 21:35 ` Matt Ochs [this message]
2026-04-29 9:29 ` Bernd Schubert
2026-04-29 10:38 ` Miklos Szeredi
2026-04-29 10:47 ` Bernd Schubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=486C7565-177D-4D6F-88DF-B7DFA3DA60F3@nvidia.com \
--to=mochs@nvidia.com \
--cc=bschubert@ddn.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.