* [PATCH net] vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting
From: Stefano Garzarella @ 2026-04-20 13:20 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, Simon Horman, Stefano Garzarella, kvm,
Arseniy Krasnov, David S. Miller, Paolo Abeni, Jakub Kicinski,
Michael S. Tsirkin, Jason Wang, virtualization, linux-kernel,
Eugenio Pérez, Xuan Zhuo, Stefan Hajnoczi, Yiming Qian
From: Stefano Garzarella <sgarzare@redhat.com>
virtio_transport_init_zcopy_skb() uses iter->count as the size argument
for msg_zerocopy_realloc(), which in turn passes it to
mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this
function is called after virtio_transport_fill_skb() has already consumed
the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->count
will be 0, skipping the RLIMIT_MEMLOCK enforcement.
Pass pkt_len (the total bytes being sent) as an explicit parameter to
virtio_transport_init_zcopy_skb() instead of reading the already-consumed
iter->count.
This matches TCP and UDP, which both call msg_zerocopy_realloc() with
the original message size.
Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 0742091beae7..416d533f493d 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -73,6 +73,7 @@ static bool virtio_transport_can_zcopy(const struct virtio_transport *t_ops,
static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
struct sk_buff *skb,
struct msghdr *msg,
+ size_t pkt_len,
bool zerocopy)
{
struct ubuf_info *uarg;
@@ -81,12 +82,10 @@ static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
uarg = msg->msg_ubuf;
net_zcopy_get(uarg);
} else {
- struct iov_iter *iter = &msg->msg_iter;
struct ubuf_info_msgzc *uarg_zc;
uarg = msg_zerocopy_realloc(sk_vsock(vsk),
- iter->count,
- NULL, false);
+ pkt_len, NULL, false);
if (!uarg)
return -1;
@@ -398,11 +397,17 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
* each iteration. If this is last skb for this buffer
* and MSG_ZEROCOPY mode is in use - we must allocate
* completion for the current syscall.
+ *
+ * Pass pkt_len because msg iter is already consumed
+ * by virtio_transport_fill_skb(), so iter->count
+ * can not be used for RLIMIT_MEMLOCK pinned-pages
+ * accounting done by msg_zerocopy_realloc().
*/
if (info->msg && info->msg->msg_flags & MSG_ZEROCOPY &&
skb_len == rest_len && info->op == VIRTIO_VSOCK_OP_RW) {
if (virtio_transport_init_zcopy_skb(vsk, skb,
info->msg,
+ pkt_len,
can_zcopy)) {
kfree_skb(skb);
ret = -ENOMEM;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] virtiofs: add FUSE protocol validation
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Yuto Ohnuki, Stefan Hajnoczi, Miklos Szeredi, Sasha Levin,
gmaglione, vgoyal, miklos, virtualization, linux-fsdevel,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Yuto Ohnuki <ytohnuki@amazon.com>
[ Upstream commit 68b69fa0edb241a946cd4c850110990f30705164 ]
Add virtio_fs_verify_response() to validate that the server properly
follows the FUSE protocol by checking:
- Response length is at least sizeof(struct fuse_out_header).
- oh.len matches the actual response length.
- oh.unique matches the request's unique identifier.
On validation failure, set error to -EIO and normalize oh.len to prevent
underflow in copy_args_from_argbuf().
Addresses the TODO comment in virtio_fs_request_complete().
Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a comprehensive analysis. Let
me compile my findings.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: virtiofs (fs/fuse)
- Action verb: "add" — but the body reveals this is actually a bug fix
(prevents underflow in `copy_args_from_argbuf()`)
- Summary: Adds FUSE protocol response validation to prevent memory
corruption from invalid server responses
**Step 1.2: Tags**
- Signed-off-by: Yuto Ohnuki (author)
- Reviewed-by: Stefan Hajnoczi (original virtiofs author, Red Hat)
- Signed-off-by: Miklos Szeredi (FUSE subsystem maintainer)
- No Fixes: tag (expected for autosel)
- No Cc: stable (expected)
- No Reported-by (proactive fix addressing long-standing TODO)
**Step 1.3: Commit Body**
- Explicitly states: "normalize oh.len to prevent underflow in
copy_args_from_argbuf()"
- Addresses a known TODO since 2020 (commit bb737bbe48bea9)
- Three specific checks: minimum length, oh.len match, oh.unique match
**Step 1.4: Hidden Bug Fix Detection**
YES — this is a bug fix disguised as "add validation." The key phrase is
"prevent underflow in copy_args_from_argbuf()." Looking at line 732 of
`copy_args_from_argbuf()`:
```732:732:fs/fuse/virtio_fs.c
remaining = req->out.h.len - sizeof(req->out.h);
```
If `req->out.h.len < sizeof(req->out.h)` (16 bytes), `remaining` is
`unsigned int` and underflows to ~4 billion. This `remaining` is then
used to control `memcpy` at line 746 — a buffer overflow.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Files: fs/fuse/virtio_fs.c only
- Lines: +25 added, -4 removed (net +21)
- Functions modified: `virtio_fs_requests_done_work()` (4 lines added)
- Function added: `virtio_fs_verify_response()` (22 lines)
- TODO comment removed from `virtio_fs_request_complete()`
- Scope: single-file, surgical fix
**Step 2.2: Code Flow Change**
- BEFORE: No validation of server responses. `virtqueue_get_buf()`
returns response → immediately processed by `copy_args_from_argbuf()`
with no bounds checking on `oh.len` or `oh.unique`.
- AFTER: Each response is validated before processing. Invalid responses
get `error = -EIO` and `oh.len = sizeof(struct fuse_out_header)`,
preventing underflow.
**Step 2.3: Bug Mechanism**
Category: **Buffer overflow / memory safety fix** — specifically
preventing unsigned integer underflow leading to out-of-bounds memcpy.
Three failure modes without this fix:
1. `oh.len < sizeof(fuse_out_header)`: `remaining` underflows → massive
memcpy → buffer overflow
2. `oh.len != actual_len`: `remaining` doesn't match actual buffer →
over-read/over-write
3. `oh.unique` mismatch: response processed for wrong request → data
corruption
**Step 2.4: Fix Quality**
- Obviously correct: simple comparisons against known-good values
- Minimal/surgical: only adds validation, no behavioral changes to valid
responses
- No regression risk: valid responses pass through unchanged; invalid
ones get -EIO (safe)
- Well-contained: single file, single subsystem
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- `copy_args_from_argbuf()`: introduced by Stefan Hajnoczi in
a62a8ef9d97da2 (2018-06-12) — the original virtiofs driver
- The TODO comment was added by Vivek Goyal in bb737bbe48bea9
(2020-04-20) when refactoring the request completion path
- The buggy code (lack of validation) has existed since virtiofs was
first introduced in 2018
**Step 3.2: Fixes tag**: None present (expected)
**Step 3.3: File History**: The file has 86 changes since v5.4. Recent
changes are unrelated (kzalloc_obj conversions, sysfs fixes, folio
conversions).
**Step 3.4: Author**: Yuto Ohnuki has 8 other commits in the tree (xfs,
ext4, igbvf, ixgbevf). Active kernel contributor at Amazon.
**Step 3.5: Dependencies**: None. The fix is entirely self-contained. It
uses existing structures (`fuse_out_header`, `fuse_req`) and doesn't
depend on any recent changes.
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1: Original Discussion**
- Submitted: Feb 16, 2026 by Yuto Ohnuki
- Stefan Hajnoczi (original virtiofs author) gave Reviewed-by same day
(Feb 17)
- Miklos Szeredi (FUSE maintainer) replied "Applied, thanks." same day
(Feb 17)
- Single-version patch (no v2/v3), applied immediately
- A competing patch by Li Wang (March 18, 2026) was submitted later —
Stefan noted this patch was already applied
**Step 4.2: Reviewers**
- Stefan Hajnoczi: original virtiofs author, Red Hat — provided
Reviewed-by
- Miklos Szeredi: FUSE subsystem maintainer — applied the patch
- Proper mailing lists CC'd: virtualization, linux-fsdevel, linux-kernel
**Step 4.3: Bug Report**: No formal bug report. This was a proactive fix
addressing a known TODO in the code.
**Step 4.5: Stable Discussion**: No explicit stable nomination found.
The fact that another developer independently submitted the same fix (Li
Wang) shows the issue was recognized by multiple people.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions Modified**
- `virtio_fs_verify_response()` (new)
- `virtio_fs_requests_done_work()` (caller of validation)
**Step 5.2: Callers**
- `virtio_fs_requests_done_work()` is the work function for ALL request
completions off the virtqueue
- Called via `schedule_work()` from `virtio_fs_vq_done()`, the virtqueue
interrupt handler
- Every FUSE response goes through this path
**Step 5.4: Call Chain**
```
virtio_fs_vq_done() [virtqueue interrupt]
→ schedule_work(&fsvq->done_work)
→ virtio_fs_requests_done_work()
→ virtqueue_get_buf(vq, &len) [gets response from virtqueue]
→ **virtio_fs_verify_response(req, len)** [NEW: validates
response]
→ ... → virtio_fs_request_complete()
→ copy_args_from_argbuf() [contains the underflow
vulnerability]
```
The validation is placed correctly — before `copy_args_from_argbuf()` is
called through any path.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: Buggy Code Exists in Stable**
- The original `copy_args_from_argbuf()` with the unvalidated
`remaining` calculation was introduced in 2018 (a62a8ef9d97da2)
- virtiofs exists in all kernels since v5.4
- The vulnerability exists in ALL stable trees: 5.4.y, 5.10.y, 5.15.y,
6.1.y, 6.6.y, 6.12.y, 7.0.y
**Step 6.2: Backport Complications**
- The code around the affected area is very stable — hasn't changed
significantly
- The patch should apply cleanly or with trivial offset adjustments
- No conflicting refactors in the validation insertion point
**Step 6.3: Related Fixes**: No other fix for this issue exists in
stable.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem Criticality**
- virtiofs (fs/fuse): IMPORTANT — used in VM environments (QEMU, cloud)
- Used in containers, cloud workloads, development environments
- Security boundary: guest kernel trusting host FUSE server responses
**Step 7.2: Activity**: Active subsystem with 86 changes since v5.4.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected Users**
- All users of virtiofs (VM guests mounting host filesystems via virtio-
fs)
- Cloud users, container users, QEMU/KVM users
**Step 8.2: Trigger Conditions**
- A malicious or buggy virtiofs server (virtiofsd) sends a response
with:
- `oh.len < 16` (trigger underflow)
- `oh.len != actual_response_len` (trigger buffer mismatch)
- Wrong `oh.unique` (trigger data corruption)
- In a VM security context, this is security-relevant: a compromised
host could exploit this to corrupt guest kernel memory
**Step 8.3: Failure Mode Severity**
- **CRITICAL**: unsigned integer underflow → massive memcpy → buffer
overflow → kernel memory corruption
- This can lead to: kernel crash (oops/panic), data corruption, or
potential code execution in the guest kernel
**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Prevents memory corruption from malicious/buggy FUSE server
responses — HIGH
- RISK: 25 lines of simple validation logic, obviously correct — VERY
LOW
- Ratio: Very favorable for backport
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence Compilation**
FOR backport:
- Fixes real unsigned underflow → buffer overflow vulnerability in
`copy_args_from_argbuf()`
- Security-relevant in VM environments (host→guest attack vector)
- Small, surgical fix (25 lines added, 4 removed)
- Obviously correct (simple comparisons)
- Reviewed by original virtiofs author (Stefan Hajnoczi)
- Applied by FUSE maintainer (Miklos Szeredi)
- No dependencies — completely standalone
- Bug exists in all stable trees since v5.4
- Another developer independently tried to fix the same issue (validates
its importance)
AGAINST backport:
- Commit message says "add" not "fix" — but the body explicitly mentions
preventing underflow
- No formal bug report or syzbot report — proactive fix
- Requires a malicious/buggy server to trigger (but this IS the threat
model for VMs)
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — simple bounds checking,
reviewed by subsystem experts
2. Fixes a real bug? **YES** — unsigned underflow → buffer overflow
3. Important issue? **YES** — memory corruption (CRITICAL severity)
4. Small and contained? **YES** — 25 lines, single file
5. No new features or APIs? **YES** — only adds validation
6. Can apply to stable? **YES** — no dependencies, code unchanged since
2018
**Step 9.3: Exception Categories**: N/A — this qualifies as a regular
bug fix
**Step 9.4: Decision**
This commit fixes a genuine memory safety vulnerability — an unsigned
integer underflow in `copy_args_from_argbuf()` that leads to a buffer
overflow via `memcpy`. The fix is small (25 lines), obviously correct
(simple comparison checks), reviewed by the original virtiofs author,
and applied by the FUSE maintainer. The vulnerable code has existed
since virtiofs was introduced in 2018, affecting all stable trees from
v5.4 onward.
## Verification
- [Phase 1] Parsed tags: Reviewed-by Stefan Hajnoczi, Signed-off-by
Miklos Szeredi (FUSE maintainer)
- [Phase 2] Diff analysis: +25/-4 lines in fs/fuse/virtio_fs.c; adds
`virtio_fs_verify_response()` and 4-line caller
- [Phase 2] Verified underflow: line 732 `remaining = req->out.h.len -
sizeof(req->out.h)` — unsigned int subtraction with no bounds check →
underflow when oh.len < 16
- [Phase 2] Verified memcpy consequence: line 746
`memcpy(args->out_args[i].value, req->argbuf + offset, argsize)` uses
the underflowed `remaining`
- [Phase 3] git blame: buggy code introduced in a62a8ef9d97da2
(2018-06-12, Stefan Hajnoczi, virtiofs initial implementation)
- [Phase 3] git blame: TODO comment added by bb737bbe48bea9 (2020-04-20,
Vivek Goyal)
- [Phase 3] git tag: original code exists since v5.4 (confirmed via git
log v5.4 -- fs/fuse/virtio_fs.c)
- [Phase 4] Lore discussion: original patch at
spinics.net/lists/kernel/msg6051405.html — single version, applied
immediately
- [Phase 4] Stefan Hajnoczi provided Reviewed-by (Feb 17, 2026)
- [Phase 4] Miklos Szeredi replied "Applied, thanks." (Feb 17, 2026)
- [Phase 4] Competing fix by Li Wang (March 2026) confirms independent
recognition of the issue
- [Phase 5] Traced call chain: virtqueue interrupt → done_work →
virtio_fs_requests_done_work() → validation → copy_args_from_argbuf()
- [Phase 5] Confirmed all response processing paths go through the
validation point
- [Phase 6] Code exists unchanged in stable 7.0 tree (verified by
reading current file, lines 724-759)
- [Phase 6] No conflicting changes — patch should apply cleanly
- [Phase 8] Failure mode: unsigned underflow → buffer overflow → kernel
memory corruption (CRITICAL)
- UNVERIFIED: Exact clean-apply status on older stable trees (5.10,
5.15, 6.1) — minor offset adjustments may be needed due to folio
conversions
**YES**
fs/fuse/virtio_fs.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 057e65b51b99d..2f7485ffac527 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -758,6 +758,27 @@ static void copy_args_from_argbuf(struct fuse_args *args, struct fuse_req *req)
req->argbuf = NULL;
}
+/* Verify that the server properly follows the FUSE protocol */
+static bool virtio_fs_verify_response(struct fuse_req *req, unsigned int len)
+{
+ struct fuse_out_header *oh = &req->out.h;
+
+ if (len < sizeof(*oh)) {
+ pr_warn("virtio-fs: response too short (%u)\n", len);
+ return false;
+ }
+ if (oh->len != len) {
+ pr_warn("virtio-fs: oh.len mismatch (%u != %u)\n", oh->len, len);
+ return false;
+ }
+ if (oh->unique != req->in.h.unique) {
+ pr_warn("virtio-fs: oh.unique mismatch (%llu != %llu)\n",
+ oh->unique, req->in.h.unique);
+ return false;
+ }
+ return true;
+}
+
/* Work function for request completion */
static void virtio_fs_request_complete(struct fuse_req *req,
struct virtio_fs_vq *fsvq)
@@ -767,10 +788,6 @@ static void virtio_fs_request_complete(struct fuse_req *req,
unsigned int len, i, thislen;
struct folio *folio;
- /*
- * TODO verify that server properly follows FUSE protocol
- * (oh.uniq, oh.len)
- */
args = req->args;
copy_args_from_argbuf(args, req);
@@ -824,6 +841,10 @@ static void virtio_fs_requests_done_work(struct work_struct *work)
virtqueue_disable_cb(vq);
while ((req = virtqueue_get_buf(vq, &len)) != NULL) {
+ if (!virtio_fs_verify_response(req, len)) {
+ req->out.h.error = -EIO;
+ req->out.h.len = sizeof(struct fuse_out_header);
+ }
spin_lock(&fpq->lock);
list_move_tail(&req->list, &reqs);
spin_unlock(&fpq->lock);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/4] scsi: qedi: Fix command overqueueing
From: Bart Van Assche @ 2026-04-20 16:45 UTC (permalink / raw)
To: Mike Christie, martin.petersen, linux-scsi, james.bottomley,
virtualization, mst, pbonzini, stefanha, eperezma
In-Reply-To: <20260417230751.117836-3-michael.christie@oracle.com>
On 4/17/26 3:57 PM, Mike Christie wrote:
> qedi supports a total of can_queue commands over all queues so set
> host_tagset when multiple queues are used.
>
> Signed-off-by: Mike Christie <michael.christie@oracle.com>
> ---
> drivers/scsi/qedi/qedi_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
> index 227ff7bd1bdc..0be0a9f30ee2 100644
> --- a/drivers/scsi/qedi/qedi_main.c
> +++ b/drivers/scsi/qedi/qedi_main.c
> @@ -657,6 +657,8 @@ static struct qedi_ctx *qedi_host_alloc(struct pci_dev *pdev)
> qedi->max_sqes = QEDI_SQ_SIZE;
>
> shost->nr_hw_queues = MIN_NUM_CPUS_MSIX(qedi);
> + if (shost->nr_hw_queues > 1)
> + shost->host_tagset = 1;
>
> pci_set_drvdata(pdev, qedi);
>
Why "if (shost->nr_hw_queues > 1)"? It is safe to set host_tagset even
if shost->nr_hw_queues == 1. See e.g. "[PATCH] ufs: core: Use a host-
wide tagset in SDB mode"
(https://lore.kernel.org/linux-scsi/20260116180800.3085233-1-bvanassche@acm.org/).
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 3/4] scsi: Support scsi_devices without a device wide limit
From: Bart Van Assche @ 2026-04-20 16:51 UTC (permalink / raw)
To: Mike Christie, martin.petersen, linux-scsi, james.bottomley,
virtualization, mst, pbonzini, stefanha, eperezma
In-Reply-To: <20260417230751.117836-4-michael.christie@oracle.com>
On 4/17/26 3:57 PM, Mike Christie wrote:
> +#define SCSI_UNLIMITED_CMD_PER_LUN -1
> /*
> * True if this host adapter can make good use of linked commands.
> * This will allow more than one command to be queued to a given
> @@ -451,6 +452,9 @@ struct scsi_host_template {
> * command block per lun, 2 for two, etc. Do not set this to 0.
> * You should make sure that the host adapter will do the right thing
> * before you try setting this above 1.
> + *
> + * Adapters that do not have a device limit can set this to
> + * SCSI_UNLIMITED_CMD_PER_LUN.
> */
> short cmd_per_lun;
Please make sure that SCSI_UNLIMITED_CMD_PER_LUN has type "short"
instead of "int". Otherwise comparisons like "shost->cmd_per_lun !=
SCSI_UNLIMITED_CMD_PER_LUN" will trigger a conversion from "short" to
"int" for "shost->cmd_per_lun" before the actual conversion happens. I
don't think that's what we want ...
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 4/4] virtio-scsi: Support scsi_devices without a device wide limit
From: Stefan Hajnoczi @ 2026-04-20 17:30 UTC (permalink / raw)
To: Mike Christie
Cc: martin.petersen, linux-scsi, james.bottomley, virtualization, mst,
pbonzini, eperezma
In-Reply-To: <20260417230751.117836-5-michael.christie@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
On Fri, Apr 17, 2026 at 05:57:24PM -0500, Mike Christie wrote:
> When exporting a NVMe drive or other high perf multiqueue enabled
> devices we may want to pass commands from the guest to the physical
> device without been throttled for artificial device wide limits. To
> allow the user to tell virtio-scsi that we don't have a LU wide
> command limit, this patch uses U32_MAX as a special cmd_per_lun value.
>
> If U32_MAX is used for cmd_per_lun, virtio-scsi will set
> SCSI_UNLIMITED_CMD_PER_LUN for the scsi_device's queue limit. In this
> case there is no scsi_device wide queue limit and we only go by the
> the virtqueue limits (virtqueue limit is translated to scsi host
> can_queue which is translated to block layer per hardware queue limit).
>
> There's a small chance of regression where an existing user could be
> using U32_MAX and we have been setting the cmd_per_lun to can_queue.
> However, I think in the cases the user was doing this, they will want
> the new behavior where they are only limited by can_queue because
> they have been trying to get the highest queue value possible.
>
> Signed-off-by: Mike Christie <michael.christie@oracle.com>
> ---
> drivers/scsi/virtio_scsi.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Hi Mike,
Please send a VIRTIO spec patch documenting the new meaning of U32_MAX
in the virtio-scsi's cmd_per_lun configuration field to
virtio-comment@lists.linux.dev. See
https://github.com/oasis-tcs/virtio-spec for details.
The Linux driver patches need to be be merged after the VIRTIO spec
change has been merged so that Linux stays spec-compliant and to avoid
collisions between in-progress VIRTIO changes.
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] scsi: Support devices that don't have a cmd_per_lun limit
From: Stefan Hajnoczi @ 2026-04-20 17:33 UTC (permalink / raw)
To: Mike Christie
Cc: martin.petersen, linux-scsi, james.bottomley, virtualization, mst,
pbonzini, eperezma
In-Reply-To: <20260417230751.117836-1-michael.christie@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
On Fri, Apr 17, 2026 at 05:57:20PM -0500, Mike Christie wrote:
> The following patches were made over Linus's and Martin's 7.1 trees.
> They fix an issue where for virtio-scsi we export a lot of non-scsi
> devices but are getting throttled by the cmd_per_lun_limit too early.
> For example we export 1 or more NVMe or block devices and would like
> to just pass command to them in way where virtio-scsi's hw queue
> limits match the physical hardware. Or in some cases we are doing
> cgroup based throttling on the host side, and we don't want the guest
> to block IO when the host knows we have extra bandwidth.
>
> The patches add a new cmd_per_lun value so drivers can indicate
> when to avoid tracking queueing at the device wide level. They
> then rely on just the block layer hw queue limits. And the patches
> convert virtio-scsi. They also fix some can_queue related issues
> discovered while testing/reviewing.
Hi Mike,
Is there a difference between setting cmd_per_lun to U32_MAX with your
patches versus setting cmd_per_lun to the virtqueue size without your
patches (this can already be done today without code changes in the
driver)?
Thanks,
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] virtio-scsi: Support scsi_devices without a device wide limit
From: Bart Van Assche @ 2026-04-20 17:37 UTC (permalink / raw)
To: Mike Christie, martin.petersen, linux-scsi, james.bottomley,
virtualization, mst, pbonzini, stefanha, eperezma
In-Reply-To: <20260417230751.117836-5-michael.christie@oracle.com>
On 4/17/26 3:57 PM, Mike Christie wrote:
> cmd_per_lun = virtscsi_config_get(vdev, cmd_per_lun) ?: 1;
> - shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue);
> + if (cmd_per_lun == U32_MAX)
> + shost->cmd_per_lun = SCSI_UNLIMITED_CMD_PER_LUN;
> + else
> + shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue);
Although this has not been introduced by this patch: shost->cmd_per_lun
is a signed 16-bits variable and can_queue has type u32 so the above
assignment can cause integer truncation.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 2/4] scsi: qedi: Fix command overqueueing
From: Mike Christie @ 2026-04-20 17:47 UTC (permalink / raw)
To: Bart Van Assche, martin.petersen, linux-scsi, james.bottomley,
virtualization, mst, pbonzini, stefanha, eperezma
In-Reply-To: <197fd58e-2cc7-4ed8-a662-52120f39c5e2@acm.org>
On 4/20/26 11:45 AM, Bart Van Assche wrote:
> On 4/17/26 3:57 PM, Mike Christie wrote:
>> qedi supports a total of can_queue commands over all queues so set
>> host_tagset when multiple queues are used.
>>
>> Signed-off-by: Mike Christie <michael.christie@oracle.com>
>> ---
>> drivers/scsi/qedi/qedi_main.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/
>> qedi_main.c
>> index 227ff7bd1bdc..0be0a9f30ee2 100644
>> --- a/drivers/scsi/qedi/qedi_main.c
>> +++ b/drivers/scsi/qedi/qedi_main.c
>> @@ -657,6 +657,8 @@ static struct qedi_ctx *qedi_host_alloc(struct
>> pci_dev *pdev)
>> qedi->max_sqes = QEDI_SQ_SIZE;
>> shost->nr_hw_queues = MIN_NUM_CPUS_MSIX(qedi);
>> + if (shost->nr_hw_queues > 1)
>> + shost->host_tagset = 1;
>> pci_set_drvdata(pdev, qedi);
>
> Why "if (shost->nr_hw_queues > 1)"? It is safe to set host_tagset even
> if shost->nr_hw_queues == 1. See e.g. "[PATCH] ufs: core: Use a host-
> wide tagset in SDB mode" (https://lore.kernel.org/linux-
> scsi/20260116180800.3085233-1-bvanassche@acm.org/).
>
But you can't do batching with host_tagset right?
^ permalink raw reply
* Re: [PATCH 2/4] scsi: qedi: Fix command overqueueing
From: Bart Van Assche @ 2026-04-20 18:02 UTC (permalink / raw)
To: Mike Christie, martin.petersen, linux-scsi, james.bottomley,
virtualization, mst, pbonzini, stefanha, eperezma
In-Reply-To: <b3234b38-7eba-4628-a7df-24cd7460df14@oracle.com>
On 4/20/26 10:47 AM, Mike Christie wrote:
> On 4/20/26 11:45 AM, Bart Van Assche wrote:
>> On 4/17/26 3:57 PM, Mike Christie wrote:
>>> qedi supports a total of can_queue commands over all queues so set
>>> host_tagset when multiple queues are used.
>>>
>>> Signed-off-by: Mike Christie <michael.christie@oracle.com>
>>> ---
>>> drivers/scsi/qedi/qedi_main.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/
>>> qedi_main.c
>>> index 227ff7bd1bdc..0be0a9f30ee2 100644
>>> --- a/drivers/scsi/qedi/qedi_main.c
>>> +++ b/drivers/scsi/qedi/qedi_main.c
>>> @@ -657,6 +657,8 @@ static struct qedi_ctx *qedi_host_alloc(struct
>>> pci_dev *pdev)
>>> qedi->max_sqes = QEDI_SQ_SIZE;
>>> shost->nr_hw_queues = MIN_NUM_CPUS_MSIX(qedi);
>>> + if (shost->nr_hw_queues > 1)
>>> + shost->host_tagset = 1;
>>> pci_set_drvdata(pdev, qedi);
>>
>> Why "if (shost->nr_hw_queues > 1)"? It is safe to set host_tagset even
>> if shost->nr_hw_queues == 1. See e.g. "[PATCH] ufs: core: Use a host-
>> wide tagset in SDB mode" (https://lore.kernel.org/linux-
>> scsi/20260116180800.3085233-1-bvanassche@acm.org/).
>>
> But you can't do batching with host_tagset right?
Batching? Does this refer to struct io_comp_batch or perhaps to another
batching feature?
Thanks,
Bart.
^ permalink raw reply
* [syzbot ci] Re: mm/virtio: skip redundant zeroing of host-zeroed reported pages
From: syzbot ci @ 2026-04-20 18:09 UTC (permalink / raw)
To: aarcange, akpm, apopple, axelrasmussen, baohua, baolin.wang, bhe,
byungchul, chrisl, david, dev.jain, eperezma, gourry, hannes,
hughd, jackmanb, jasowang, joshua.hahnjy, kasong, lance.yang,
liam.howlett, linux-kernel, linux-mm, ljs, matthew.brost, mhocko,
mst, muchun.song, npache, nphamcs, osalvador, rakie.kim, rppt,
ryan.roberts, shikemeng, surenb, vbabka, virtualization, weixugc,
xuanzhuo, ying.huang, yuanchu, ziy
Cc: syzbot, syzkaller-bugs
In-Reply-To: <cover.1776689093.git.mst@redhat.com>
syzbot ci has tested the following series
[v2] mm/virtio: skip redundant zeroing of host-zeroed reported pages
https://lore.kernel.org/all/cover.1776689093.git.mst@redhat.com
* [PATCH RFC v2 01/18] mm: page_alloc: propagate PageReported flag across buddy splits
* [PATCH RFC v2 02/18] mm: add pghint_t type and vma_alloc_folio_hints API
* [PATCH RFC v2 03/18] mm: add PG_zeroed page flag for known-zero pages
* [PATCH RFC v2 04/18] mm: page_alloc: track PG_zeroed across buddy merges
* [PATCH RFC v2 05/18] mm: page_alloc: preserve PG_zeroed in try_to_claim_block
* [PATCH RFC v2 06/18] mm: page_alloc: thread pghint_t through get_page_from_freelist
* [PATCH RFC v2 07/18] mm: post_alloc_hook: use PG_zeroed to skip zeroing, return pghint_t
* [PATCH RFC v2 08/18] mm: hugetlb: thread pghint_t through buddy allocation chain
* [PATCH RFC v2 09/18] mm: hugetlb: use PG_zeroed for pool pages, skip redundant zeroing
* [PATCH RFC v2 10/18] mm: page_reporting: support host-zeroed reported pages
* [PATCH RFC v2 11/18] mm: skip zeroing in vma_alloc_zeroed_movable_folio for pre-zeroed pages
* [PATCH RFC v2 12/18] mm: skip zeroing in alloc_anon_folio for pre-zeroed pages
* [PATCH RFC v2 13/18] mm: skip zeroing in vma_alloc_anon_folio_pmd for pre-zeroed pages
* [PATCH RFC v2 14/18] mm: memfd: skip zeroing for pre-zeroed hugetlb pages
* [PATCH RFC v2 15/18] virtio_balloon: add host_zeroes_pages module parameter
* [PATCH RFC v2 16/18] mm: page_reporting: add flush parameter with page budget
* [PATCH RFC v2 17/18] mm: add free_frozen_pages_hint and put_page_hint APIs
* [PATCH RFC v2 18/18] virtio_balloon: mark deflated pages as pre-zeroed
and found the following issue:
kernel BUG in free_huge_folio
Full report is available here:
https://ci.syzbot.org/series/329d9cff-a0ad-46d2-8ff4-d9f4341a611f
***
kernel BUG in free_huge_folio
tree: mm-new
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base: b8a5774cd49996e8ef83b1637a9b547158f18de9
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/60e99a0e-08bf-474f-b034-a8bfd2eb90b0/config
syz repro: https://ci.syzbot.org/findings/2868ce13-1752-4f9f-9aa9-c5ce89f01fc7/syz_repro
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page_owner free stack trace missing
------------[ cut here ]------------
kernel BUG at ./include/linux/page-flags.h:698!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 6015 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:__ClearPageZeroed include/linux/page-flags.h:698 [inline]
RIP: 0010:free_huge_folio+0xf93/0x12e0 mm/hugetlb.c:1749
Code: c7 c6 a0 64 db 8b e8 5c 9b fe fe 90 0f 0b e8 74 40 9c ff eb 05 e8 6d 40 9c ff 48 89 df 48 c7 c6 e0 63 db 8b e8 3e 9b fe fe 90 <0f> 0b e8 56 40 9c ff 48 89 df 48 c7 c6 40 64 db 8b e8 27 9b fe fe
RSP: 0018:ffffc90003a675b8 EFLAGS: 00010246
RAX: c71fb9abd148e700 RBX: ffffea0005808000 RCX: 0000000000000000
RDX: 0000000000000007 RSI: ffffffff8defcd3f RDI: 00000000ffffffff
RBP: 1ffffd4000b0101a R08: ffffffff9011ddb7 R09: 1ffffffff2023bb6
R10: dffffc0000000000 R11: fffffbfff2023bb7 R12: ffffea0005808008
R13: ffffea00058080d0 R14: ffffffff9a2e27c0 R15: 0000000000000040
FS: 00007fe11abed6c0(0000) GS:ffff8882a9453000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe119de9f00 CR3: 00000001ba914000 CR4: 00000000000006f0
Call Trace:
<TASK>
__folio_put+0xfc/0x4f0 mm/swap.c:105
hugetlb_mfill_atomic_pte+0x130a/0x1730 mm/hugetlb.c:6294
mfill_atomic_hugetlb mm/userfaultfd.c:601 [inline]
mfill_atomic mm/userfaultfd.c:773 [inline]
mfill_atomic_copy+0xe28/0x1420 mm/userfaultfd.c:872
userfaultfd_copy fs/userfaultfd.c:1642 [inline]
userfaultfd_ioctl+0x2c17/0x5130 fs/userfaultfd.c:2059
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe119d9c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe11abed028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fe11a015fa0 RCX: 00007fe119d9c819
RDX: 00002000000000c0 RSI: 00000000c028aa03 RDI: 0000000000000003
RBP: 00007fe119e32c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe11a016038 R14: 00007fe11a015fa0 R15: 00007ffe7cd6ce28
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__ClearPageZeroed include/linux/page-flags.h:698 [inline]
RIP: 0010:free_huge_folio+0xf93/0x12e0 mm/hugetlb.c:1749
Code: c7 c6 a0 64 db 8b e8 5c 9b fe fe 90 0f 0b e8 74 40 9c ff eb 05 e8 6d 40 9c ff 48 89 df 48 c7 c6 e0 63 db 8b e8 3e 9b fe fe 90 <0f> 0b e8 56 40 9c ff 48 89 df 48 c7 c6 40 64 db 8b e8 27 9b fe fe
RSP: 0018:ffffc90003a675b8 EFLAGS: 00010246
RAX: c71fb9abd148e700 RBX: ffffea0005808000 RCX: 0000000000000000
RDX: 0000000000000007 RSI: ffffffff8defcd3f RDI: 00000000ffffffff
RBP: 1ffffd4000b0101a R08: ffffffff9011ddb7 R09: 1ffffffff2023bb6
R10: dffffc0000000000 R11: fffffbfff2023bb7 R12: ffffea0005808008
R13: ffffea00058080d0 R14: ffffffff9a2e27c0 R15: 0000000000000040
FS: 00007fe11abed6c0(0000) GS:ffff8882a9453000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe119de9f00 CR3: 00000001ba914000 CR4: 00000000000006f0
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages
From: David Hildenbrand (Arm) @ 2026-04-20 18:20 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: Andrew Morton, Vlastimil Babka, Brendan Jackman, Michal Hocko,
Suren Baghdasaryan, Jason Wang, Andrea Arcangeli, linux-mm,
virtualization
In-Reply-To: <cover.1776689093.git.mst@redhat.com>
On 4/20/26 14:51, Michael S. Tsirkin wrote:
>
Hi!
>
> v2 - this is an attempt to address David Hildenbrand's comments:
> overloading GFP and using page->private, support for
> balloon deflate.
>
> I hope this one is acceptable, API wise.
>
> I also went ahead and implemented an alternative approach
> that David suggested:
> using GFP_ZERO to zero userspace pages.
> The issue is simple: on some architectures, one has to know the
> userspace fault address in order to flush the cache.
>
> So, I had to propagate the fault address everywhere.
As I said, that might not be necessary. vma_alloc_folio() is the
interface we mostly care about in that regard.
> A lot of churn, and my concern is, if we miss even one
> place, silent, subtle data corruption will result and only
> on some arches (x86 will be fine).
Which would *already* be the case of you use folio_alloc(GFP_ZERO)
instead of magical vma_alloc_folio() + folio_zero_user().
I don't really see how vma_alloc_folio_hints() -- that also consumes the
address -- is any better in that regard?
When we just do the right thing with vma_alloc_folio(GFP_ZERO), at least
vma_alloc_folio() users will not accidentally do the wrong thing by
forgetting to use folio_zero_user().
>
> Still, you can view that approach here:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git gfp_zero
>
> David, if you still feel I should switch to that approach,
> let me know. Personally, I'd rather keep that as a separate
> project from this optimization.
I'd prefer if we extend vma_alloc_folio() to just handle GFP_ZERO for us.
But let's hear other opinions first.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH net] vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting
From: Bobby Eshleman @ 2026-04-20 18:34 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, Eric Dumazet, Simon Horman, kvm, Arseniy Krasnov,
David S. Miller, Paolo Abeni, Jakub Kicinski, Michael S. Tsirkin,
Jason Wang, virtualization, linux-kernel, Eugenio Pérez,
Xuan Zhuo, Stefan Hajnoczi, Yiming Qian
In-Reply-To: <20260420132051.217589-1-sgarzare@redhat.com>
On Mon, Apr 20, 2026 at 03:20:51PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella <sgarzare@redhat.com>
>
> virtio_transport_init_zcopy_skb() uses iter->count as the size argument
> for msg_zerocopy_realloc(), which in turn passes it to
> mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this
> function is called after virtio_transport_fill_skb() has already consumed
> the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->count
> will be 0, skipping the RLIMIT_MEMLOCK enforcement.
>
> Pass pkt_len (the total bytes being sent) as an explicit parameter to
> virtio_transport_init_zcopy_skb() instead of reading the already-consumed
> iter->count.
>
> This matches TCP and UDP, which both call msg_zerocopy_realloc() with
> the original message size.
>
> Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> net/vmw_vsock/virtio_transport_common.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 0742091beae7..416d533f493d 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -73,6 +73,7 @@ static bool virtio_transport_can_zcopy(const struct virtio_transport *t_ops,
> static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
> struct sk_buff *skb,
> struct msghdr *msg,
> + size_t pkt_len,
> bool zerocopy)
> {
> struct ubuf_info *uarg;
> @@ -81,12 +82,10 @@ static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
> uarg = msg->msg_ubuf;
> net_zcopy_get(uarg);
> } else {
> - struct iov_iter *iter = &msg->msg_iter;
> struct ubuf_info_msgzc *uarg_zc;
>
> uarg = msg_zerocopy_realloc(sk_vsock(vsk),
> - iter->count,
> - NULL, false);
> + pkt_len, NULL, false);
> if (!uarg)
> return -1;
>
> @@ -398,11 +397,17 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> * each iteration. If this is last skb for this buffer
> * and MSG_ZEROCOPY mode is in use - we must allocate
> * completion for the current syscall.
> + *
> + * Pass pkt_len because msg iter is already consumed
> + * by virtio_transport_fill_skb(), so iter->count
> + * can not be used for RLIMIT_MEMLOCK pinned-pages
> + * accounting done by msg_zerocopy_realloc().
> */
> if (info->msg && info->msg->msg_flags & MSG_ZEROCOPY &&
> skb_len == rest_len && info->op == VIRTIO_VSOCK_OP_RW) {
> if (virtio_transport_init_zcopy_skb(vsk, skb,
> info->msg,
> + pkt_len,
> can_zcopy)) {
> kfree_skb(skb);
> ret = -ENOMEM;
> --
> 2.53.0
>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
^ permalink raw reply
* Re: [PATCH 2/4] scsi: qedi: Fix command overqueueing
From: Mike Christie @ 2026-04-20 18:48 UTC (permalink / raw)
To: Bart Van Assche, martin.petersen, linux-scsi, james.bottomley,
virtualization, mst, pbonzini, stefanha, eperezma
In-Reply-To: <b59beef1-ed3a-4eb4-a1bf-c45e5be2764b@acm.org>
On 4/20/26 1:02 PM, Bart Van Assche wrote:
> On 4/20/26 10:47 AM, Mike Christie wrote:
>> On 4/20/26 11:45 AM, Bart Van Assche wrote:
>>> On 4/17/26 3:57 PM, Mike Christie wrote:
>>>> qedi supports a total of can_queue commands over all queues so set
>>>> host_tagset when multiple queues are used.
>>>>
>>>> Signed-off-by: Mike Christie <michael.christie@oracle.com>
>>>> ---
>>>> drivers/scsi/qedi/qedi_main.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/ qedi_main.c
>>>> index 227ff7bd1bdc..0be0a9f30ee2 100644
>>>> --- a/drivers/scsi/qedi/qedi_main.c
>>>> +++ b/drivers/scsi/qedi/qedi_main.c
>>>> @@ -657,6 +657,8 @@ static struct qedi_ctx *qedi_host_alloc(struct pci_dev *pdev)
>>>> qedi->max_sqes = QEDI_SQ_SIZE;
>>>> shost->nr_hw_queues = MIN_NUM_CPUS_MSIX(qedi);
>>>> + if (shost->nr_hw_queues > 1)
>>>> + shost->host_tagset = 1;
>>>> pci_set_drvdata(pdev, qedi);
>>>
>>> Why "if (shost->nr_hw_queues > 1)"? It is safe to set host_tagset even
>>> if shost->nr_hw_queues == 1. See e.g. "[PATCH] ufs: core: Use a host-
>>> wide tagset in SDB mode" (https://lore.kernel.org/linux- scsi/20260116180800.3085233-1-bvanassche@acm.org/).
>>>
>> But you can't do batching with host_tagset right?
>
> Batching? Does this refer to struct io_comp_batch or perhaps to another
> batching feature?
>
I was talking about when we unplug a queue we try to allocate
the tags/requests in a batch. But, ignore my comment. I mixed up
BLK_MQ_F_TAG_QUEUE_SHARED and BLK_MQ_F_TAG_HCTX_SHARED.
I'll fix my patch.
^ permalink raw reply
* Re: [PATCH] Bluetooth: virtio_bt: clamp rx length before skb_put
From: Luiz Augusto von Dentz @ 2026-04-20 19:17 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, Soenke Huster,
Michael S . Tsirkin, virtualization
In-Reply-To: <20260418000138.1848813-1-michael.bommarito@gmail.com>
Hi Michael,
On Fri, Apr 17, 2026 at 8:01 PM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> virtbt_rx_work() calls skb_put(skb, len) where len comes directly
> from virtqueue_get_buf() with no validation against the skb we
> posted. The RX skb is allocated as alloc_skb(1000) in
> virtbt_add_inbuf(). A malicious or buggy virtio-bt backend that
> reports used.len larger than the skb's tailroom causes skb_put() to
> call skb_over_panic() in net/core/skbuff.c, which triggers
> BUG() and panics the guest.
>
> Reproduced on a QEMU 9.0 whose virtio-bt backend reports
> used.len = 4096 into a 1000-byte rx skb:
>
> skbuff: skb_over_panic: text:ffffffff83958e84 len:4096 put:4096
> head:ffff88800c071000 data:ffff88800c071000 tail:0x1000
> end:0x6c0 dev:<NULL>
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:214!
> Call Trace:
> skb_panic+0x160/0x162
> skb_put.cold+0x31/0x31
> virtbt_rx_work+0x94/0x250
> process_one_work+0x80d/0x1510
> worker_thread+0x4af/0xd20
> kthread+0x2cc/0x3a0
>
> Reject any len that exceeds skb_tailroom(). Drop the skb on the
> error path; virtbt_add_inbuf() reposts a fresh one for the next
> iteration. With the check in place the same harness runs without
> BUG(); the driver logs "rx reply len %u exceeds skb tailroom %u"
> and the device keeps running.
>
> Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"),
> which hardened the USB 9p transport against unchecked device-reported length.
>
> Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length")
> Cc: stable@vger.kernel.org
> Cc: Soenke Huster <soenke.huster@eknoes.de>
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Assisted-by: Claude:claude-opus-4-7
> ---
> drivers/bluetooth/virtio_bt.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
> index 76d61af8a275..157e68b6e75f 100644
> --- a/drivers/bluetooth/virtio_bt.c
> +++ b/drivers/bluetooth/virtio_bt.c
> @@ -227,8 +227,15 @@ static void virtbt_rx_work(struct work_struct *work)
> if (!skb)
> return;
>
> - skb_put(skb, len);
> - virtbt_rx_handle(vbt, skb);
> + if (len > skb_tailroom(skb)) {
> + bt_dev_err(vbt->hdev,
> + "rx reply len %u exceeds skb tailroom %u\n",
> + len, skb_tailroom(skb));
> + kfree_skb(skb);
> + } else {
> + skb_put(skb, len);
> + virtbt_rx_handle(vbt, skb);
> + }
>
> if (virtbt_add_inbuf(vbt) < 0)
> return;
> --
> 2.53.0
https://sashiko.dev/#/patchset/20260418000138.1848813-1-michael.bommarito%40gmail.com
All seem like valid comments to me, first one is odd to me thought,
never would have though that skb_tailroom wouldn't be enough to check
if using `skb_put` is safe.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH net v2] hv_sock: Report EOF instead of -EIO for FIN
From: patchwork-bot+netdevbpf @ 2026-04-20 21:59 UTC (permalink / raw)
To: Dexuan Cui
Cc: kys, haiyangz, wei.liu, longli, sgarzare, davem, edumazet, kuba,
pabeni, horms, niuxuewei.nxw, linux-hyperv, virtualization,
netdev, linux-kernel, stable, Ben.Hillis, levymitchell0
In-Reply-To: <20260416191433.840637-1-decui@microsoft.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 12:14:33 -0700 you wrote:
> Commit f0c5827d07cb unluckily causes a regression for the FIN packet,
> and the final read syscall gets an error rather than 0.
>
> Ideally, we would want to fix hvs_channel_readable_payload() so that it
> could return 0 in the FIN scenario, but it's not good for the hv_sock
> driver to use the VMBus ringbuffer's cached priv_read_index, which is
> internal data in the VMBus driver.
>
> [...]
Here is the summary with links:
- [net,v2] hv_sock: Report EOF instead of -EIO for FIN
https://git.kernel.org/netdev/net/c/f63152958994
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [syzbot] [kvm?] [net?] [virt?] BUG: sleeping function called from invalid context in vhost_get_avail_idx
From: syzbot @ 2026-04-20 22:09 UTC (permalink / raw)
To: eperezma, jasowang, kvm, linux-kernel, mst, netdev,
syzkaller-bugs, virtualization
Hello,
syzbot found the following issue on:
HEAD commit: 8541d8f725c6 Merge tag 'mtd/for-7.1' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=136454ce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=7e54da1916e8d11f
dashboard link: https://syzkaller.appspot.com/bug?extid=6985cb8e543ea90ba8ee
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d264ce580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=143ec1ba580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-8541d8f7.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/22dfea2c37c2/vmlinux-8541d8f7.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e2f93ad68fe3/bzImage-8541d8f7.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6985cb8e543ea90ba8ee@syzkaller.appspotmail.com
BUG: sleeping function called from invalid context at drivers/vhost/vhost.c:1527
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6110, name: vhost-6109
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
2 locks held by vhost-6109/6110:
#0: ffff888055624cb0 (&vq->mutex/1){+.+.}-{4:4}, at: handle_tx+0x2d/0x160 drivers/vhost/net.c:971
#1: ffff888055620248 (&vq->mutex){+.+.}-{4:4}, at: vhost_net_busy_poll+0x9c/0x730 drivers/vhost/net.c:554
Preemption disabled at:
[<ffffffff88f1a006>] vhost_net_busy_poll+0x1c6/0x730 drivers/vhost/net.c:563
CPU: 0 UID: 0 PID: 6110 Comm: vhost-6109 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
__might_resched.cold+0x1ec/0x232 kernel/sched/core.c:9162
__might_fault+0x8b/0x140 mm/memory.c:7322
vhost_get_avail_idx+0x31c/0x4f0 drivers/vhost/vhost.c:1527
vhost_vq_avail_empty drivers/vhost/vhost.c:3206 [inline]
vhost_vq_avail_empty+0xa9/0xe0 drivers/vhost/vhost.c:3199
vhost_net_busy_poll+0x297/0x730 drivers/vhost/net.c:574
vhost_net_tx_get_vq_desc drivers/vhost/net.c:610 [inline]
get_tx_bufs.constprop.0+0x338/0x600 drivers/vhost/net.c:650
handle_tx_copy+0x28c/0x12e0 drivers/vhost/net.c:778
handle_tx+0x139/0x160 drivers/vhost/net.c:985
vhost_run_work_list+0x183/0x220 drivers/vhost/vhost.c:454
vhost_task_fn+0x156/0x430 kernel/vhost_task.c:49
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages
From: Michael S. Tsirkin @ 2026-04-20 23:33 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-kernel, Andrew Morton, Vlastimil Babka, Brendan Jackman,
Michal Hocko, Suren Baghdasaryan, Jason Wang, Andrea Arcangeli,
linux-mm, virtualization
In-Reply-To: <c199e47d-b2fd-42f3-9e50-c47c848dc72f@kernel.org>
On Mon, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote:
> On 4/20/26 14:51, Michael S. Tsirkin wrote:
> >
>
> Hi!
>
> >
> > v2 - this is an attempt to address David Hildenbrand's comments:
> > overloading GFP and using page->private, support for
> > balloon deflate.
> >
> > I hope this one is acceptable, API wise.
> >
> > I also went ahead and implemented an alternative approach
> > that David suggested:
> > using GFP_ZERO to zero userspace pages.
> > The issue is simple: on some architectures, one has to know the
> > userspace fault address in order to flush the cache.
> >
> > So, I had to propagate the fault address everywhere.
>
> As I said, that might not be necessary. vma_alloc_folio() is the
> interface we mostly care about in that regard.
>
I'm not sure I follow what "might not be necessary". We need a fault
address so zeroing can be effective wrt cache. Since you asked that it's
done deep in post alloc hook, the address has to propagate all over mm.
> > A lot of churn, and my concern is, if we miss even one
> > place, silent, subtle data corruption will result and only
> > on some arches (x86 will be fine).
>
> Which would *already* be the case of you use folio_alloc(GFP_ZERO)
> instead of magical vma_alloc_folio() + folio_zero_user().
>
> I don't really see how vma_alloc_folio_hints() -- that also consumes the
> address -- is any better in that regard?
By itself, it is not. But the issue is propagating the address from
there all over mm. If we miss even one place - we get a subtle cache
corruption on non x86.
hints are exactly that - if we forget to set them, all that happens
is that we do an extra zeroing. That is all.
> When we just do the right thing with vma_alloc_folio(GFP_ZERO), at least
> vma_alloc_folio() users will not accidentally do the wrong thing by
> forgetting to use folio_zero_user().
Well, it's simply that
1. if you plain forget folio_zero_user you get non zero on all arches
2. we *already* have folio_zero_user in place
> >
> > Still, you can view that approach here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git gfp_zero
> >
> > David, if you still feel I should switch to that approach,
> > let me know. Personally, I'd rather keep that as a separate
> > project from this optimization.
> I'd prefer if we extend vma_alloc_folio() to just handle GFP_ZERO for us.
Pls take a look at that tree then. What do you think of that approach?
Better? If you want it in form of patches, I can post them
in private or on list.
Let me know, I don't have a problem with that approach - I tested
it and the performance is the same. But the issue is that there's lot
of paths that have to propagate the fault address. It took me a while to
even find them all (assuming I found them all).
I also note that we need a flag for free in order to implement
balloon deflate as you asked. Here, I reused the hints.
> But let's hear other opinions first.
>
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH RFC v2 02/18] mm: add pghint_t type and vma_alloc_folio_hints API
From: Huang, Ying @ 2026-04-21 0:58 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Andrew Morton, David Hildenbrand, Vlastimil Babka,
Brendan Jackman, Michal Hocko, Suren Baghdasaryan, Jason Wang,
Andrea Arcangeli, linux-mm, virtualization, Johannes Weiner,
Zi Yan, Lorenzo Stoakes, Liam R. Howlett, Mike Rapoport,
Matthew Brost, Joshua Hahn, Rakie Kim, Byungchul Park,
Gregory Price, Alistair Popple
In-Reply-To: <290d615a001cf121dc0c604eb79451bcc7917baa.1776689093.git.mst@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> Add pghint_t, a bitwise type for communicating page allocation hints
> between the allocator and callers. Define PGHINT_ZEROED to indicate
> that the allocated page contents are known to be zero.
>
> Add _hints variants of the allocation functions that accept a
> pghint_t *hints output parameter:
>
> vma_alloc_folio_hints() -> folio_alloc_mpol_hints (internal)
> -> __alloc_frozen_pages_hints()
>
> The existing APIs are unchanged and continue to work without hints.
> For now, hints is always initialized to 0. A subsequent patch will
> set PGHINT_ZEROED when the page was pre-zeroed by the host.
Why do we need this feature? Is there any performance impact? If so,
please provide some performance data.
[snip]
---
Best Regards,
Huang, Ying
^ permalink raw reply
* Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages
From: Gregory Price @ 2026-04-21 2:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Andrew Morton, David Hildenbrand, Vlastimil Babka,
Brendan Jackman, Michal Hocko, Suren Baghdasaryan, Jason Wang,
Andrea Arcangeli, linux-mm, virtualization
In-Reply-To: <cover.1776689093.git.mst@redhat.com>
On Mon, Apr 20, 2026 at 08:51:13AM -0400, Michael S. Tsirkin wrote:
>
> When a guest reports free pages to the hypervisor via virtio-balloon's
> free page reporting, the host typically zeros those pages when reclaiming
> their backing memory (e.g., via MADV_DONTNEED on anonymous mappings).
> When the guest later reallocates those pages, the kernel zeros them
> again -- redundantly.
>
It took me a second to really wrap my head around what you were saying
here, but if i'm following correctly:
1) Guest steals a page, reports the free page to the host
2) Host returns that page to the buddy
3) Guest wants the page back -> vmexit, alloc()
a) host gets a page from the buddy via fault path
b) this memory is "user memory" so host zeroes the page
4) Guest repeats step 3, re-zeoring the page
So you're adding a step that does:
1) page_reporting_drain() in guest sets PG_zeroed if host_zeroes_pages=true
2) on allocation, if PG_zeroed is set, don't zero
In theory this seems ok. PG_zeroed being a buddy-only flag is nice.
In practice there are obvious concerns about an explicit flag that would
allow a kernel (in this case the guest) to skip zeroing a page destined
for userland mappings - but i'm also paranoid.
In concept this seems reasonable, in implementation I have concerns
about the pghint_t type being added. Will respond inline in David's
reply thread on that though where you already have notes.
~Gregory
^ permalink raw reply
* Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages
From: Gregory Price @ 2026-04-21 2:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Hildenbrand (Arm), linux-kernel, Andrew Morton,
Vlastimil Babka, Brendan Jackman, Michal Hocko,
Suren Baghdasaryan, Jason Wang, Andrea Arcangeli, linux-mm,
virtualization
In-Reply-To: <20260420192037-mutt-send-email-mst@kernel.org>
On Mon, Apr 20, 2026 at 07:33:38PM -0400, Michael S. Tsirkin wrote:
> On Mon, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote:
> > On 4/20/26 14:51, Michael S. Tsirkin wrote:
>
> > > A lot of churn, and my concern is, if we miss even one
> > > place, silent, subtle data corruption will result and only
> > > on some arches (x86 will be fine).
> >
> > Which would *already* be the case of you use folio_alloc(GFP_ZERO)
> > instead of magical vma_alloc_folio() + folio_zero_user().
> >
> > I don't really see how vma_alloc_folio_hints() -- that also consumes the
> > address -- is any better in that regard?
>
> By itself, it is not. But the issue is propagating the address from
> there all over mm. If we miss even one place - we get a subtle cache
> corruption on non x86.
>
Why does it need to propogate?
Can we leave folio_zero_user() callers the same, but add a PG_zeroed
check in folio_zero_user() that skips the zeroing (but not the cache
flush) and clear the PG_zeroed bit?
Is this feasible?
You don't eliminate the folio_zero_user(), but maybe we shouldn't?
(a bit naive here - i haven't checked the PG_zeroed lifetime, i did
see it overloads PG_private - so this might not be feasible)
>
> I also note that we need a flag for free in order to implement
> balloon deflate as you asked. Here, I reused the hints.
>
I'd sooner just implement this as
___put_folio(folio, gfp_t)
__put_folio(folio) { ___put_folio(folio, NULL); }
And change the free path to take overloaded gfp flags.
Some of the existing ones might even be useful as-is.
It's essentially the same thing, but prevents a bunch of churn and
saves us a new concept.
optional gfp flags on free seem like genuinely useful interface for
certain callers (definitely not all).
~Gregory
^ permalink raw reply
* [PATCH net v3] hv_sock: Report EOF instead of -EIO for FIN
From: Dexuan Cui @ 2026-04-21 2:59 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, sgarzare, davem, edumazet,
kuba, pabeni, horms, niuxuewei.nxw, linux-hyperv, virtualization,
netdev, linux-kernel
Cc: stable, Ben Hillis, Mitchell Levy
Commit f0c5827d07cb unluckily causes a regression for the FIN packet,
and the final read syscall gets an error rather than 0.
Ideally, we would want to fix hvs_channel_readable_payload() so that it
could return 0 in the FIN scenario, but it's not good for the hv_sock
driver to use the VMBus ringbuffer's cached priv_read_index, which is
internal data in the VMBus driver.
Fix the regression in hv_sock by returning 0 rather than -EIO.
In case we see a malformed/short packet, we still return -EIO.
Fixes: f0c5827d07cb ("hv_sock: Return the readable bytes in hvs_stream_has_data()")
Cc: stable@vger.kernel.org
Reported-by: Ben Hillis <Ben.Hillis@microsoft.com>
Reported-by: Mitchell Levy <levymitchell0@gmail.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
Changes since v1:
Removed the local variable 'need_refill' to make the code more
readable. Stefano, thanks!
No other change.
Changes since v2:
Added code to test the flag SEND_SHUTDOWN. Copilot, thanks!
Updated the comment and the commit messages accordingly.
net/vmw_vsock/hyperv_transport.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 069386a74557..da150de10f0d 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -694,7 +694,6 @@ static ssize_t hvs_stream_enqueue(struct vsock_sock *vsk, struct msghdr *msg,
static s64 hvs_stream_has_data(struct vsock_sock *vsk)
{
struct hvsock *hvs = vsk->trans;
- bool need_refill;
s64 ret;
if (hvs->recv_data_len > 0)
@@ -702,9 +701,31 @@ static s64 hvs_stream_has_data(struct vsock_sock *vsk)
switch (hvs_channel_readable_payload(hvs->chan)) {
case 1:
- need_refill = !hvs->recv_desc;
- if (!need_refill)
- return -EIO;
+ if (hvs->recv_desc) {
+ /* Here hvs->recv_data_len is 0, so hvs->recv_desc must
+ * be NULL unless it points to the 0-byte-payload FIN
+ * packet or a malformed/short packet: see
+ * hvs_update_recv_data().
+ *
+ * If hvs->recv_desc points to the FIN packet, here all
+ * the payload has been dequeued and the peer_shutdown
+ * flag is set, but hvs_channel_readable_payload() still
+ * returns 1, because the VMBus ringbuffer's read_index
+ * is not updated for the FIN packet:
+ * hvs_stream_dequeue() -> hv_pkt_iter_next() updates
+ * the cached priv_read_index but has no opportunity to
+ * update the read_index in hv_pkt_iter_close() as
+ * hvs_stream_has_data() returns 0 for the FIN packet,
+ * so it won't get dequeued.
+ *
+ * In case hvs->recv_desc points to a malformed/short
+ * packet, return -EIO.
+ */
+ if (hvs->vsk->peer_shutdown & SEND_SHUTDOWN)
+ return 0;
+ else
+ return -EIO;
+ }
hvs->recv_desc = hv_pkt_iter_first(hvs->chan);
if (!hvs->recv_desc)
--
2.49.0
^ permalink raw reply related
* RE: [EXTERNAL] Re: [PATCH net v2] hv_sock: Report EOF instead of -EIO for FIN
From: Dexuan Cui @ 2026-04-21 3:13 UTC (permalink / raw)
To: patchwork-bot+netdevbpf@kernel.org, kuba@kernel.org,
sgarzare@redhat.com
Cc: KY Srinivasan, Haiyang Zhang, wei.liu@kernel.org, Long Li,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
horms@kernel.org, niuxuewei.nxw@antgroup.com,
linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Ben Hillis, levymitchell0@gmail.com
In-Reply-To: <177672238581.1802062.15838493180057695674.git-patchwork-notify@kernel.org>
> From: patchwork-bot+netdevbpf@kernel.org <patchwork-
> bot+netdevbpf@kernel.org>
> Sent: Monday, April 20, 2026 3:00 PM
> > [...]
>
> Here is the summary with links:
> - [net,v2] hv_sock: Report EOF instead of -EIO for FIN
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f63152958994
Hi Jakub, Stefano,
I'm sorry -- I just posted v3
https://lore.kernel.org/linux-hyperv/20260421025950.1099495-1-decui@microsoft.com/T/#u
and then I realized that the v2 had been merged into the main branch :-(
Should I post a new delta patch(with a Fixes tag against the v2) based on the main branch?
Thanks,
Dexuan
^ permalink raw reply
* [PATCH v2] drm/qxl: Convert qxl release idr to xarray
From: liuqiangneo @ 2026-04-21 6:00 UTC (permalink / raw)
To: airlied, kraxel
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona,
virtualization, spice-devel, dri-devel, linux-kernel, Qiang Liu
From: Qiang Liu <liuqiang@kylinos.cn>
Replace the release_idr + release_idr_lock to an XArray.
IDR internally uses xarray so we can use it directly which simplifies our
code by removing the need to do external locking.
Signed-off-by: Qiang Liu <liuqiang@kylinos.cn>
---
v2:
- Use xa_limit_31b instead of xa_limit_32b to keep IDs within INT_MAX.
- Use GFP_KERNEL instead of GFP_NOWAIT because the context is sleepable.
- Cast to u32 to avoid sign extension when atomic counter wraps above INT_MAX.
---
drivers/gpu/drm/qxl/qxl_drv.h | 6 ++---
drivers/gpu/drm/qxl/qxl_kms.c | 4 +--
drivers/gpu/drm/qxl/qxl_release.c | 45 ++++++++++++++-----------------
3 files changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index cc02b5f10ad9..cf9decf39022 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -35,6 +35,7 @@
#include <linux/firmware.h>
#include <linux/platform_device.h>
#include <linux/workqueue.h>
+#include <linux/xarray.h>
#include <drm/drm_crtc.h>
#include <drm/drm_encoder.h>
@@ -208,11 +209,10 @@ struct qxl_device {
struct qxl_memslot surfaces_slot;
spinlock_t release_lock;
- struct idr release_idr;
- uint32_t release_seqno;
+ struct xarray release_xa;
+ atomic_t release_seqno;
atomic_t release_count;
wait_queue_head_t release_event;
- spinlock_t release_idr_lock;
struct mutex async_io_mutex;
unsigned int last_sent_io_cmd;
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 461b7ab9ad5c..0cebaf88f407 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -227,8 +227,8 @@ int qxl_device_init(struct qxl_device *qdev,
goto cursor_ring_free;
}
- idr_init_base(&qdev->release_idr, 1);
- spin_lock_init(&qdev->release_idr_lock);
+ xa_init_flags(&qdev->release_xa, XA_FLAGS_ALLOC1);
+ atomic_set(&qdev->release_seqno, 0);
spin_lock_init(&qdev->release_lock);
idr_init_base(&qdev->surf_id_idr, 1);
diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c
index 06979d0e8a9f..929df641b62d 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -90,6 +90,7 @@ qxl_release_alloc(struct qxl_device *qdev, int type,
struct qxl_release *release;
int handle;
size_t size = sizeof(*release);
+ int r;
release = kmalloc(size, GFP_KERNEL);
if (!release) {
@@ -102,16 +103,12 @@ qxl_release_alloc(struct qxl_device *qdev, int type,
release->surface_release_id = 0;
INIT_LIST_HEAD(&release->bos);
- idr_preload(GFP_KERNEL);
- spin_lock(&qdev->release_idr_lock);
- handle = idr_alloc(&qdev->release_idr, release, 1, 0, GFP_NOWAIT);
- release->base.seqno = ++qdev->release_seqno;
- spin_unlock(&qdev->release_idr_lock);
- idr_preload_end();
- if (handle < 0) {
+ r = xa_alloc(&qdev->release_xa, &handle, release, xa_limit_31b, GFP_KERNEL);
+ release->base.seqno = (u32)atomic_inc_return(&qdev->release_seqno);
+ if (r < 0) {
kfree(release);
*ret = NULL;
- return handle;
+ return r;
}
*ret = release;
DRM_DEBUG_DRIVER("allocated release %d\n", handle);
@@ -143,9 +140,7 @@ qxl_release_free(struct qxl_device *qdev,
if (release->surface_release_id)
qxl_surface_id_dealloc(qdev, release->surface_release_id);
- spin_lock(&qdev->release_idr_lock);
- idr_remove(&qdev->release_idr, release->id);
- spin_unlock(&qdev->release_idr_lock);
+ xa_erase(&qdev->release_xa, release->id);
if (dma_fence_was_initialized(&release->base)) {
WARN_ON(list_empty(&release->bos));
@@ -261,14 +256,14 @@ int qxl_alloc_surface_release_reserved(struct qxl_device *qdev,
struct qxl_release **release)
{
if (surface_cmd_type == QXL_SURFACE_CMD_DESTROY && create_rel) {
- int idr_ret;
+ int xa_ret;
struct qxl_bo *bo;
union qxl_release_info *info;
/* stash the release after the create command */
- idr_ret = qxl_release_alloc(qdev, QXL_RELEASE_SURFACE_CMD, release);
- if (idr_ret < 0)
- return idr_ret;
+ xa_ret = qxl_release_alloc(qdev, QXL_RELEASE_SURFACE_CMD, release);
+ if (xa_ret < 0)
+ return xa_ret;
bo = create_rel->release_bo;
(*release)->release_bo = bo;
@@ -277,7 +272,7 @@ int qxl_alloc_surface_release_reserved(struct qxl_device *qdev,
qxl_release_list_add(*release, bo);
info = qxl_release_map(qdev, *release);
- info->id = idr_ret;
+ info->id = xa_ret;
qxl_release_unmap(qdev, *release, info);
return 0;
}
@@ -291,7 +286,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev, unsigned long size,
struct qxl_bo **rbo)
{
struct qxl_bo *bo, *free_bo = NULL;
- int idr_ret;
+ int xa_ret;
int ret = 0;
union qxl_release_info *info;
int cur_idx;
@@ -312,11 +307,11 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev, unsigned long size,
return -EINVAL;
}
- idr_ret = qxl_release_alloc(qdev, type, release);
- if (idr_ret < 0) {
+ xa_ret = qxl_release_alloc(qdev, type, release);
+ if (xa_ret < 0) {
if (rbo)
*rbo = NULL;
- return idr_ret;
+ return xa_ret;
}
atomic_inc(&qdev->release_count);
@@ -362,7 +357,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev, unsigned long size,
}
info = qxl_release_map(qdev, *release);
- info->id = idr_ret;
+ info->id = xa_ret;
qxl_release_unmap(qdev, *release, info);
return ret;
@@ -373,11 +368,11 @@ struct qxl_release *qxl_release_from_id_locked(struct qxl_device *qdev,
{
struct qxl_release *release;
- spin_lock(&qdev->release_idr_lock);
- release = idr_find(&qdev->release_idr, id);
- spin_unlock(&qdev->release_idr_lock);
+ xa_lock(&qdev->release_xa);
+ release = xa_load(&qdev->release_xa, id);
+ xa_unlock(&qdev->release_xa);
if (!release) {
- DRM_ERROR("failed to find id in release_idr\n");
+ DRM_ERROR("failed to find id in release_xa\n");
return NULL;
}
--
2.43.0
^ permalink raw reply related
* [PATCH] virtio_console: add timeout to __send_to_port() spin loop
From: Peng Yang @ 2026-04-21 6:57 UTC (permalink / raw)
To: Amit Shah, Arnd Bergmann, Greg Kroah-Hartman
Cc: kernel, virtualization, linux-kernel, Peng Yang
__send_to_port() busy-waits in virtqueue_get_buf() while holding
outvq_lock with IRQs disabled. If the host stops draining the TX
virtqueue, this loop never terminates.
This was observed during secondary VM boot: virtio_mem plugged memory
in multiple iterations, each emitting dev_info() messages through the
hvc console. A writev() on the hvc TTY entered __send_to_port() and
stalled in the spin loop. When the watchdog bark ISR fired on another
CPU, it attempted printk(), which tried to acquire outvq_lock through
the same path and spun indefinitely. With all CPUs stuck, the watchdog
could not be serviced and triggered a bite.
Add a 200 ms deadline using ktime_get_mono_fast_ns() to bound the spin
loop. ktime_get_mono_fast_ns() reads the hardware counter directly and
is safe to call with IRQs disabled and spinlocks held.
The 200 ms value is chosen to be far above normal host response latency
(microseconds) to avoid spurious exits, yet well below the watchdog
bark-to-bite window (typically 3 s) so that CPUs can escape the loop
and complete the bark handler before a bite occurs.
Signed-off-by: Peng Yang <peng.yang@oss.qualcomm.com>
---
drivers/char/virtio_console.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 9a33217c68d9..b3535681dfe1 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -27,6 +27,7 @@
#include <linux/module.h>
#include <linux/dma-mapping.h>
#include <linux/string_choices.h>
+#include <linux/timekeeping.h>
#include "../tty/hvc/hvc_console.h"
#define is_rproc_enabled IS_ENABLED(CONFIG_REMOTEPROC)
@@ -601,6 +602,7 @@ static ssize_t __send_to_port(struct port *port, struct scatterlist *sg,
int err;
unsigned long flags;
unsigned int len;
+ u64 deadline;
out_vq = port->out_vq;
@@ -632,10 +634,18 @@ static ssize_t __send_to_port(struct port *port, struct scatterlist *sg,
* buffer and relax the spinning requirement. The downside is
* we need to kmalloc a GFP_ATOMIC buffer each time the
* console driver writes something out.
+ *
+ * To avoid spinning forever if the host stops processing the
+ * TX virtqueue (e.g. during VM shutdown), a 200ms deadline is
+ * used to break out of the loop as a fallback.
*/
- while (!virtqueue_get_buf(out_vq, &len)
- && !virtqueue_is_broken(out_vq))
+ deadline = ktime_get_mono_fast_ns() + 200ULL * NSEC_PER_MSEC;
+ while (!virtqueue_get_buf(out_vq, &len) &&
+ !virtqueue_is_broken(out_vq)) {
+ if (ktime_get_mono_fast_ns() >= deadline)
+ break;
cpu_relax();
+ }
done:
spin_unlock_irqrestore(&port->outvq_lock, flags);
---
base-commit: 97e797263a5e963da3d1e66e743fd518567dfe37
change-id: 20260420-add_timeout_to___send_to_port-104ce7bcf241
Best regards,
--
Peng Yang <peng.yang@oss.qualcomm.com>
^ permalink raw reply related
* Re: [EXTERNAL] Re: [PATCH net v2] hv_sock: Report EOF instead of -EIO for FIN
From: Stefano Garzarella @ 2026-04-21 7:28 UTC (permalink / raw)
To: Dexuan Cui
Cc: patchwork-bot+netdevbpf@kernel.org, kuba@kernel.org,
KY Srinivasan, Haiyang Zhang, wei.liu@kernel.org, Long Li,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
horms@kernel.org, niuxuewei.nxw@antgroup.com,
linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Ben Hillis, levymitchell0@gmail.com
In-Reply-To: <SA1PR21MB69214CABCA0DCD597040F849BF2C2@SA1PR21MB6921.namprd21.prod.outlook.com>
On Tue, 21 Apr 2026 at 05:13, Dexuan Cui <DECUI@microsoft.com> wrote:
>
> > From: patchwork-bot+netdevbpf@kernel.org <patchwork-
> > bot+netdevbpf@kernel.org>
> > Sent: Monday, April 20, 2026 3:00 PM
> > > [...]
> >
> > Here is the summary with links:
> > - [net,v2] hv_sock: Report EOF instead of -EIO for FIN
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f63152958994
>
> Hi Jakub, Stefano,
> I'm sorry -- I just posted v3
> https://lore.kernel.org/linux-hyperv/20260421025950.1099495-1-decui@microsoft.com/T/#u
> and then I realized that the v2 had been merged into the main branch :-(
>
> Should I post a new delta patch(with a Fixes tag against the v2) based on the main branch?
Ehm, I'm not sure about the process but if it's merged in net tree,
maybe we need a follow up patch.
Anyway, let's wait for Jakub's or other net maintainers' suggestions.
Thanks,
Stefano
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox