From: Yuho Choi <oss.patchbox@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "Joanne Koong" <joannelkoong@gmail.com>,
"Jeff Layton" <jlayton@kernel.org>,
"Vivek Goyal" <vgoyal@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"German Maglione" <gmaglione@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
fuse-devel@lists.linux.dev, virtualization@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
"Yuho Choi" <oss.patchbox@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH v1] fuse: Don't use request timeouts on virtiofs
Date: Thu, 12 Nov 2026 00:21:50 -0500 [thread overview]
Message-ID: <20261112052208.1248312-2-oss.patchbox@gmail.com> (raw)
virtiofs cannot abort a request once it has been added to a virtqueue,
because the device owns its buffers until it returns them on the used
ring. This is why virtiofs sets no_control and no_force_umount; see
commit 15c8e72e88e0 ("fuse: allow skipping control interface and
forced unmount"), which says that "virtio-fs does not support aborting
requests which are being processed".
The request timeout added by commit 0f6439f61a6e ("fuse: add
kernel-enforced timeout option for requests") aborts them anyway. When
a request takes longer than the timeout, fuse_check_timeout() calls
fuse_chan_abort(), which moves the requests on each virtqueue's
fpq->processing list to its end list and ends them, so they are freed.
The device can then still write the reply into the freed request and
its pages, and virtio_fs_requests_done_work() later gets the freed
request back from virtqueue_get_buf().
The timeout is armed when the server sets FUSE_REQUEST_TIMEOUT in its
INIT reply, or when the fs.fuse.default_request_timeout or
fs.fuse.max_request_timeout sysctl is set, for example for other FUSE
mounts on the same system. A slow host is then enough to hit it.
Don't arm the request timeout, and don't offer FUSE_REQUEST_TIMEOUT, on
connections that set no_force_umount.
Fixes: 0f6439f61a6e ("fuse: add kernel-enforced timeout option for requests")
Cc: stable@vger.kernel.org
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
---
I used no_force_umount to tell these connections apart, since virtiofs
sets it for the same reason. A separate flag would work as well if you
prefer that.
Tested on x86_64 under KVM, on top of v7.4-rc1 (6628e7d4c6b2) with KASAN
enabled, using QEMU's vhost-user-fs-pci and the C virtiofsd from QEMU 6.2:
1. In the guest, set fs.fuse.default_request_timeout=15 and mount
virtiofs.
2. On the host, stop virtiofsd with SIGSTOP.
3. In the guest, cat a file on the mount.
4. After 50 seconds, resume virtiofsd with SIGCONT.
Without this patch, the cat fails with ECONNABORTED after about 26
seconds. Once virtiofsd resumes, the guest reports:
BUG: KASAN: slab-use-after-free in virtio_fs_requests_done_work+0x7be/0xbc0
Read of size 8 at addr ffff888005176020 by task kworker/1:1/29
Workqueue: events virtio_fs_requests_done_work
...
Allocated by task 81:
fuse_request_alloc+0x19/0x200
fuse_get_req+0x153/0x2d0
fuse_chan_send+0x4cf/0x840
fuse_do_getattr+0x23a/0x4b0
...
Freed by task 81:
kmem_cache_free+0xbc/0x3e0
fuse_chan_send+0x4af/0x840
fuse_do_getattr+0x23a/0x4b0
...
Oops: general protection fault, probably for non-canonical address 0xe012fc11a000000a
RIP: 0010:virtio_fs_requests_done_work+0x25a/0xbc0
Setting fs.fuse.max_request_timeout=15 instead gives the same result.
With this patch, under either sysctl, the cat waits until virtiofsd
resumes and then returns the file contents, and the mount keeps working.
I could not test the FUSE_REQUEST_TIMEOUT part, because this virtiofsd
does not know about flags2.
The tests above were run with help from an AI agent.
fs/fuse/inode.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 1341b681d0ed..f1aae9b5475c 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -1451,7 +1451,14 @@ static void process_init_reply(struct fuse_args *args, int error)
fc->no_flock = 1;
}
- fuse_init_server_timeout(fc->chan, timeout);
+ /*
+ * A request timeout aborts the connection, which ends the
+ * requests that are still in flight. A transport that cannot
+ * take back requests it has handed to the device, such as
+ * virtiofs, sets no_force_umount for the same reason.
+ */
+ if (!fc->no_force_umount)
+ fuse_init_server_timeout(fc->chan, timeout);
fm->sb->s_bdi->ra_pages =
min(fm->sb->s_bdi->ra_pages, ra_pages);
@@ -1502,8 +1509,10 @@ static struct fuse_init_args *fuse_new_init(struct fuse_mount *fm)
FUSE_HANDLE_KILLPRIV_V2 | FUSE_SETXATTR_EXT | FUSE_INIT_EXT |
FUSE_SECURITY_CTX | FUSE_CREATE_SUPP_GROUP |
FUSE_HAS_EXPIRE_ONLY | FUSE_DIRECT_IO_ALLOW_MMAP |
- FUSE_NO_EXPORT_SUPPORT | FUSE_HAS_RESEND | FUSE_ALLOW_IDMAP |
- FUSE_REQUEST_TIMEOUT;
+ FUSE_NO_EXPORT_SUPPORT | FUSE_HAS_RESEND | FUSE_ALLOW_IDMAP;
+ /* See process_init_reply() */
+ if (!fm->fc->no_force_umount)
+ flags |= FUSE_REQUEST_TIMEOUT;
#ifdef CONFIG_FUSE_VDAX
if (fm->fc->vdax)
flags |= FUSE_MAP_ALIGNMENT;
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
--
2.43.0
next reply other threads:[~2026-11-12 5:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 5:21 Yuho Choi [this message]
2026-11-12 5:28 ` [PATCH v1] fuse: Don't use request timeouts on virtiofs sashiko-bot
2026-11-12 6:45 ` Li Wang
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=20261112052208.1248312-2-oss.patchbox@gmail.com \
--to=oss.patchbox@gmail.com \
--cc=eperezma@redhat.com \
--cc=fuse-devel@lists.linux.dev \
--cc=gmaglione@redhat.com \
--cc=jlayton@kernel.org \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stable@vger.kernel.org \
--cc=stefanha@redhat.com \
--cc=vgoyal@redhat.com \
--cc=virtualization@lists.linux.dev \
/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.