From: Li Wang <liwang@kylinos.cn>
To: German Maglione <gmaglione@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Miklos Szeredi <miklos@szeredi.hu>
Cc: "Eugenio Pérez" <eperezma@redhat.com>,
virtualization@lists.linux.dev, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, "Li Wang" <liwang@kylinos.cn>
Subject: [PATCH v2 0/3] virtiofs: hiprio FORGET robustness and no-reply request completion
Date: Thu, 2 Apr 2026 18:44:04 +0800 [thread overview]
Message-ID: <20260402104407.11495-1-liwang@kylinos.cn> (raw)
This series fixes virtiofs completion for FUSE requests that do not use a
reply descriptor, tightens hiprio FORGET handling when virtqueue submission
fails transiently, and prevents the hiprio worker from stalling when one
FORGET must be dropped after an unrecoverable error.
The first patch addresses correctness: completing a no-reply request must
not interpret the reply header fields, otherwise it will cause underflow,
and the bounce buffer allocated for the absent out header must be freed.
The host may complete virtio requests without an out descriptor (e.g.
FUSE_FORGET). The completion path must not run copy_args_from_argbuf(),
which expects a valid fuse_out_header from the reply path. This series also
ensures virtio_fs_verify_response() runs only for real replies (FR_ISREPLY),
and frees req->argbuf on the no-reply path to avoid a per-request leak.
Changes since v1
------------------------------
Patch 1: v1 only guarded copy_args_from_argbuf() with FR_ISREPLY. v2 also
kfree(req->argbuf) when !FR_ISREPLY (the buffer was allocated in
copy_args_to_argbuf for an out header that never arrives), and gates
virtio_fs_verify_response() in virtio_fs_requests_done_work() on FR_ISREPLY
so uninitialized fuse_out_header is never verified.
Patch 2: behavior matches v1. The commit message is expanded to explain
transient GFP_ATOMIC exhaustion and why dropping the FORGET would skew
nlookup and leak kernel state.
Patch 3: behavior matches v1. The commit message documents the
return-value contract with virtio_fs_hiprio_dispatch_work() and the stall
risk on the nonzero path.
Commit messages were rewritten for clearer rationale.
Li Wang (3):
virtiofs: Complete no-reply virtio requests without parsing the out
header
virtiofs: Retry hiprio FORGET when virtqueue_add_outbuf() returns
-ENOMEM
virtiofs: Do not stall hiprio FORGET dispatch after dropping one
request
fs/fuse/virtio_fs.c | 37 +++++++++++++++++++++++++++++--------
1 file changed, 29 insertions(+), 8 deletions(-)
--
2.34.1
next reply other threads:[~2026-04-02 10:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 10:44 Li Wang [this message]
2026-04-02 10:44 ` [PATCH v2 1/3] virtiofs: Complete no-reply virtio requests without parsing the out header Li Wang
2026-04-02 10:44 ` [PATCH v2 2/3] virtiofs: Retry hiprio FORGET when virtqueue_add_outbuf() returns -ENOMEM Li Wang
2026-04-02 10:44 ` [PATCH v2 3/3] virtiofs: Do not stall hiprio FORGET dispatch after dropping one request 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=20260402104407.11495-1-liwang@kylinos.cn \
--to=liwang@kylinos.cn \
--cc=eperezma@redhat.com \
--cc=gmaglione@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox