Linux virtualization list
 help / color / mirror / Atom feed
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

             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