* Re: [PATCH v6 01/12] nvdimm: preserve flush callback errors
From: Li Chen @ 2026-06-27 8:53 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Dan Williams, Vishal Verma, Dave Jiang, Ira Weiny,
Alison Schofield, virtualization, nvdimm, linux-kernel
In-Reply-To: <CAM9Jb+hf6KEWRKtWr6PQByRQ869jL6Ws7J_ShFjKY_YicTbS_g@mail.gmail.com>
Hi Pankaj,
---- On Tue, 23 Jun 2026 17:46:20 +0800 Pankaj Gupta <pankaj.gupta.linux@gmail.com> wrote ---
> > nvdimm_flush() currently converts any non-zero provider flush error to
> > -EIO. That loses useful errno values from provider callbacks.
> >
> > A local virtio-pmem mkfs sanity test showed the masking clearly:
> >
> > wipefs: /dev/pmem0: cannot flush modified buffers: Input/output error
> > mkfs.ext4: Input/output error while writing out and closing file system
> > nd_region region0: dbg: nvdimm_flush rc=-5
> >
> > The virtio-pmem callback can return -ENOMEM when async_pmem_flush() fails
> > to allocate a child flush bio, but nvdimm_flush() hides that as -EIO before
> > pmem_submit_bio() converts it to a block status.
> >
> > Return the provider callback error directly. The generic flush path still
> > returns 0, and pmem_submit_bio() already handles errno-to-blk_status
> > conversion for bio completion.
> >
> > Signed-off-by: Li Chen <me@linux.beauty>
> > ---
> > v3->v4:
> > - New patch.
> >
> > drivers/nvdimm/region_devs.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> > index e35c2e18518f0..0cd96503c0596 100644
> > --- a/drivers/nvdimm/region_devs.c
> > +++ b/drivers/nvdimm/region_devs.c
> > @@ -1114,10 +1114,8 @@ int nvdimm_flush(struct nd_region *nd_region, struct bio *bio)
> >
> > if (!nd_region->flush)
> > rc = generic_nvdimm_flush(nd_region);
> > - else {
> > - if (nd_region->flush(nd_region, bio))
> > - rc = -EIO;
> > - }
> > + else
> > + rc = nd_region->flush(nd_region, bio);
>
> IIRC this was introduced as a generic populate error type since a
> failed flush can also propagate host-side errors, which may not be
> relevant to the guest.
> That said, we could still consider handling specific cases like
> -ENOMEM, unless there is a better approach to address this.
Ah, yes, you are absolutely right. I went too far here.
Regards,
Li
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update Jason Wang's email address
From: Jakub Kicinski @ 2026-06-27 1:04 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, virtualization, netdev, eperezma, kvm, linux-kernel
In-Reply-To: <20260626022039.96139-1-jasowang@redhat.com>
On Fri, 26 Jun 2026 10:20:38 +0800 Jason Wang wrote:
> I will use jasowangio@gmail.com for future review and discussion
Do you want to add a mailmap entry, too?
Otherwise I think you'll get CCed twice (once for MAINTAINERS and once
because you given tags to previous changes)
^ permalink raw reply
* Re: [PATCH v4] virtio_net: disable cb when NAPI is busy-polled
From: Jakub Kicinski @ 2026-06-27 0:44 UTC (permalink / raw)
To: Simon Horman, lange_tang
Cc: mst, xuanzhuo, jasowang, edumazet, virtualization, netdev,
tanglongjun
In-Reply-To: <20260626151508.1319440-1-horms@kernel.org>
On Fri, 26 Jun 2026 16:15:08 +0100 Simon Horman wrote:
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 26afa6341d161..c1e252400c0fc 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -3011,6 +3011,8 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
> > unsigned int xdp_xmit = 0;
> > bool napi_complete;
> >
> > + virtqueue_disable_cb(rq->vq);
> > +
>
> [Severity: High]
> Can this unconditionally disable the RX callback and cause a permanent network
> stall when polled by netpoll?
Good catch, Longjun just add if (budget)
^ permalink raw reply
* Re: [PATCH splitout] mm: memory-failure: serialize TestSetPageHWPoison with zone->lock
From: David Hildenbrand (Arm) @ 2026-06-26 19:50 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Miaohe Lin, Zi Yan, Andrew Morton, linux-kernel, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Muchun Song, Oscar Salvador,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain,
Barry Song, Lance Yang, Hugh Dickins, Matthew Brost, Joshua Hahn,
Rakie Kim, Byungchul Park, Gregory Price, Ying Huang,
Alistair Popple, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Axel Rasmussen, Yuanchu Xie, Wei Xu,
Chris Li, Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He,
virtualization, linux-mm, Andrea Arcangeli, Naoya Horiguchi
In-Reply-To: <20260616161353-mutt-send-email-mst@kernel.org>
On 6/16/26 23:35, Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2026 at 02:18:57PM +0200, David Hildenbrand (Arm) wrote:
>> On 6/16/26 13:40, Miaohe Lin wrote:
>>>
>>> I scanned the code and found rcu_read_unlock_special might be called in some cases.
>>> Some expensive ops, e.g. irq_work_queue_on, might be called in some corner cases.
>>> So the overhead of rcu read lock might be fluctuating.
>>
>> Right. Usually rcu_read_lock+unlock is supposed to be very lightweight, but that
>> might not be completely the case with that PREEMPT_RCU thingy ...
>>
>>>
>>>
>>> Sure. We can do that if needed.
>>>
>>>
>>> Right. hypervisor could make the issue easier to trigger...
>>>
>>>
>>> I think your proposal, although there are still some issues to be resolved, is
>>> nevertheless a good solution. We could also wait and see if anyone comes up with
>>> a better one.
>>
>> I wouldn't call it "good" ... it's the only thing I was easily able to come up
>> with :)
>>
>> The only alternative would be moving the hwpoison bit out of page->flags,
>> storing it in a sparse bitmap or sth. like that. It would be a bigger rework and
>> I am sure there are issues with that as well.
>>
>> --
>> Cheers,
>>
>> David
>
>
> I had a vague feeling using static keys should be possible somehow,
> but could not come up with anything robust.
I skimmed over it, but concluded that it's worse than what I envisioned. (e.g.,
two rcu read lock+unlock over consecutive updates).
It's also doesn't address the mf_mutex implications and the x86 thingies I
mentioned.
The rcu_is_watching() optimization is interesting, wonder though if that is
really relevant in practice.
I'll either take care of that myself or find someone that can work on this with
attention to all details.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4 1/8] media: virtio: Add protocol
From: Brian Daniels @ 2026-06-26 15:50 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Mauro Carvalho Chehab, acourbot, adelva, aesteve, changyeon,
daniel.almeida, eperezma, gnurou, gurchetansingh, hverkuil,
jasowang, linux-kernel, linux-media, mst, nicolas.dufresne,
virtualization, xuanzhuo
In-Reply-To: <fe970394-176b-4add-be68-74f6074ba78c@kernel.org>
On Thu, Jun 25, 2026 at 8:51 PM Bryan O'Donoghue <bod@kernel.org> wrote:
>
> On 25/06/2026 21:24, Brian Daniels wrote:
> > I'm not an expert here, but taking a look at those files, the vast majority of
> > those reserved fields appear to be padding to ensure the struct has 64-bit
> > alignment, which matches the use here in virtio-media as well.
> >
> > virtio_pci appears to be the only device that explicitly states the
> > reserved bytes are for future extensions. Unless there's a good a reason to
> > expect a future use case where more space is needed, I would prefer to not add
> > more at this time.
>
> I'm querying why just the one though ? Why not say four ?
>
> Perhaps something you could address in your commit log.
>
Sure I can add a note in v5. But yeah the reason is the total struct
needs to be 64-bit aligned. So it can't be an arbitrary number.
And all the current reserved fields add the minimum number of bits to
ensure the existing structs are 64-bit aligned.
Adding more means extra bytes are transferred every exchange without
adding any value, which is inefficient.
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Gleixner @ 2026-06-26 15:17 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260626125819-d8b197fc-7671-4d12-a578-9025affc52d9@linutronix.de>
On Fri, Jun 26 2026 at 13:03, Thomas Weißschuh wrote:
> On Fri, Jun 26, 2026 at 12:49:41PM +0200, Thomas Gleixner wrote:
>> On Fri, Jun 26 2026 at 10:48, Thomas Weißschuh wrote:
>> > On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
>> > (...)
>> >
>> >> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
>> >> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
>> >> tkd = &tk_core;
>> >> offs = &tk_core.timekeeper.offs_boot;
>> >> break;
>> >> + case CLOCK_AUX ... CLOCK_AUX_LAST:
>> >> + tkd = aux_get_tk_data(clock_id);
>> >> + if (!tkd)
>> >> + return false;
>> >> + offs = &tkd->timekeeper.offs_aux;
>> >> + break;
>> >
>> > 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
>> > are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
>>
>> AUX clocks are independent in the first place and the MONORAW part is
>> the "MONORAW" related to the AUX clock itself.
>>
>> > Instead 'monoraw' should be computed based on 'tk_core'.
>> > Which then also requires the sequence locking of 'tk_core'.
>>
>> No. From a PTP and steering point of view you want the "raw" value which
>> is related to the AUX clock itself and not the global one.
>
> Ack.
>
> However the kdocs call it 'CLOCK_MONOTONIC_RAW'. Can we clean this up?
Yes. Something like the below?
Thanks,
tglx
---
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1202,10 +1202,21 @@ static inline u64 tk_clock_read_snapshot
/**
* ktime_get_snapshot_id - Simultaneously snapshot a given clock ID with
- * CLOCK_MONOTONIC_RAW and the underlying
+ * the corresponding monotonic raw the underlying
* clocksource counter value.
* @clock_id: The clock ID to snapshot
* @systime_snapshot: Pointer to struct receiving the system time snapshot
+ *
+ * For the system time keeping clocks (REALTIME, MONOTONIC and BOOTTIME) the
+ * monotonic raw clock is CLOCK_MONOTONIC_RAW. For AUX clocks this is the
+ * monotonic raw clock related to the AUX clock. These AUX clock related
+ * monotonic raw clocks have a strict linear offset to the system time
+ * CLOCK_MONOTONIC_RAW:
+ *
+ * MONOTONIC_RAW(AUX$N) = CLOCK_MONOTONIC_RAW(system) + offset(AUX$N)
+ *
+ * The offset is established when a AUX clock is initialized, but it is
+ * currently not accessible.
*/
void ktime_get_snapshot_id(clockid_t clock_id, struct system_time_snapshot *systime_snapshot)
{
@@ -1512,6 +1523,9 @@ EXPORT_SYMBOL_GPL(ktime_real_to_base_clo
* @xtstamp: Receives simultaneously captured system and device time
*
* Reads a timestamp from a device and correlates it to system time
+ *
+ * See documentation for ktime_get_snapshot_id() for information about the raw
+ * monotonic time stamp which is used here.
*/
int get_device_system_crosststamp(int (*get_time_fn)
(ktime_t *device_time,
^ permalink raw reply
* Re: [PATCH v4] virtio_net: disable cb when NAPI is busy-polled
From: Simon Horman @ 2026-06-26 15:15 UTC (permalink / raw)
To: lange_tang
Cc: Simon Horman, mst, xuanzhuo, jasowang, edumazet, virtualization,
netdev, tanglongjun
In-Reply-To: <20260625013733.29300-1-lange_tang@163.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
virtio_net: disable cb when NAPI is busy-polled
This commit disables the virtqueue callback at the entry of virtnet_poll().
It aims to prevent a large number of spurious interrupts when busy-poll is
active by keeping the callback off while polling.
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 26afa6341d161..c1e252400c0fc 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -3011,6 +3011,8 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
> unsigned int xdp_xmit = 0;
> bool napi_complete;
>
> + virtqueue_disable_cb(rq->vq);
> +
[Severity: High]
Can this unconditionally disable the RX callback and cause a permanent network
stall when polled by netpoll?
If the netpoll subsystem (e.g., used by netconsole) calls the NAPI poll
function directly with a budget of 0, virtqueue_disable_cb() is called
immediately. virtnet_receive() will then process 0 packets and return 0.
Later in virtnet_poll(), the completion condition is checked:
if (received < budget) {
napi_complete = virtqueue_napi_complete(napi, rq->vq, received);
...
}
When both received and budget are 0, this condition evaluates to false. This
skips virtqueue_napi_complete(), leaving the RX callback permanently disabled
and preventing the device from raising further RX interrupts.
> virtnet_poll_cleantx(rq, budget);
>
> received = virtnet_receive(rq, budget, &xdp_xmit);
^ permalink raw reply
* [PATCH net 2/2] vsock/test: add test for small packets under pressure
From: Stefano Garzarella @ 2026-06-26 13:48 UTC (permalink / raw)
To: netdev
Cc: Jason Wang, Jakub Kicinski, Paolo Abeni, Michael S. Tsirkin, kvm,
virtualization, Xuan Zhuo, Eric Dumazet, Simon Horman,
Stefano Garzarella, linux-kernel, Stefan Hajnoczi,
David S. Miller, Eugenio Pérez
In-Reply-To: <20260626134823.206676-1-sgarzare@redhat.com>
From: Stefano Garzarella <sgarzare@redhat.com>
Add a test that sends 2 MB of data using randomly sized small packets
(129-512 bytes) over a SOCK_STREAM connection. Packets above
GOOD_COPY_LEN (128) bypass the in-place coalescing in recv_enqueue(),
forcing each one into its own skb.
Without receive queue collapsing, the per-skb overhead eventually
exceeds buf_alloc and the connection is reset. The test verifies
that all data arrives and that content integrity is preserved.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
tools/testing/vsock/vsock_test.c | 87 ++++++++++++++++++++++++++++++++
1 file changed, 87 insertions(+)
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 76be0e4a7f0e..b4ff9f946565 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -2347,6 +2347,88 @@ static void test_stream_tx_credit_bounds_server(const struct test_opts *opts)
close(fd);
}
+/* Test that many small packets don't cause a connection reset under pressure
+ * and that data integrity is preserved. Packet sizes vary randomly between
+ * 129 and 512 bytes, above GOOD_COPY_LEN (128) to bypass in-place coalescing
+ * in recv_enqueue, forcing each one into its own skb. Without receive queue
+ * collapsing, the per-skb overhead eventually exceeds buf_alloc and the
+ * connection is reset.
+ */
+#define COLLAPSE_PKT_MIN 129
+#define COLLAPSE_PKT_MAX 512
+#define COLLAPSE_TOTAL (2 * 1024 * 1024)
+
+static void test_stream_collapse_client(const struct test_opts *opts)
+{
+ unsigned char *data;
+ unsigned long hash;
+ size_t offset = 0;
+ int i, fd;
+
+ data = malloc(COLLAPSE_TOTAL);
+ if (!data) {
+ perror("malloc");
+ exit(EXIT_FAILURE);
+ }
+
+ for (i = 0; i < COLLAPSE_TOTAL; i++)
+ data[i] = rand() & 0xff;
+
+ fd = vsock_stream_connect(opts->peer_cid, opts->peer_port);
+ if (fd < 0) {
+ perror("connect");
+ exit(EXIT_FAILURE);
+ }
+
+ while (offset < COLLAPSE_TOTAL) {
+ size_t pkt_size = COLLAPSE_PKT_MIN +
+ rand() % (COLLAPSE_PKT_MAX - COLLAPSE_PKT_MIN + 1);
+
+ pkt_size = min(pkt_size, COLLAPSE_TOTAL - offset);
+
+ send_buf(fd, data + offset, pkt_size, 0, pkt_size);
+ offset += pkt_size;
+ }
+
+ hash = hash_djb2(data, COLLAPSE_TOTAL);
+ control_writeulong(hash);
+
+ free(data);
+ close(fd);
+}
+
+static void test_stream_collapse_server(const struct test_opts *opts)
+{
+ unsigned long hash, remote_hash;
+ unsigned char *data;
+ int fd;
+
+ data = malloc(COLLAPSE_TOTAL);
+ if (!data) {
+ perror("malloc");
+ exit(EXIT_FAILURE);
+ }
+
+ fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
+ if (fd < 0) {
+ perror("accept");
+ exit(EXIT_FAILURE);
+ }
+
+ recv_buf(fd, data, COLLAPSE_TOTAL, 0, COLLAPSE_TOTAL);
+
+ hash = hash_djb2(data, COLLAPSE_TOTAL);
+ remote_hash = control_readulong();
+ if (hash != remote_hash) {
+ fprintf(stderr, "hash mismatch: local %lu remote %lu\n",
+ hash, remote_hash);
+ exit(EXIT_FAILURE);
+ }
+
+ free(data);
+ close(fd);
+}
+
static struct test_case test_cases[] = {
{
.name = "SOCK_STREAM connection reset",
@@ -2546,6 +2628,11 @@ static struct test_case test_cases[] = {
.run_client = test_stream_msg_peek_client,
.run_server = test_stream_peek_after_recv_server,
},
+ {
+ .name = "SOCK_STREAM small packets backpressure",
+ .run_client = test_stream_collapse_client,
+ .run_server = test_stream_collapse_server,
+ },
{},
};
--
2.54.0
^ permalink raw reply related
* [PATCH net 1/2] vsock/virtio: collapse receive queue under memory pressure
From: Stefano Garzarella @ 2026-06-26 13:48 UTC (permalink / raw)
To: netdev
Cc: Jason Wang, Jakub Kicinski, Paolo Abeni, Michael S. Tsirkin, kvm,
virtualization, Xuan Zhuo, Eric Dumazet, Simon Horman,
Stefano Garzarella, linux-kernel, Stefan Hajnoczi,
David S. Miller, Eugenio Pérez, stable, Brien Oberstein
In-Reply-To: <20260626134823.206676-1-sgarzare@redhat.com>
From: Stefano Garzarella <sgarzare@redhat.com>
When many small packets accumulate in the receive queue, the skb overhead
can exceed buf_alloc even while the payload is within bounds. This causes
virtio_transport_inc_rx_pkt() to reject packets, leading to connection
resets during large transfers under backpressure.
The issue was reported by Brien, who has a reproducer, but it is also
easily reproducible with iperf-vsock [1] using a small packet size:
iperf3 --vsock -c $CID -l 129
which fails immediately without this patch but with commit 059b7dbd20a6
("vsock/virtio: fix potential unbounded skb queue").
Inspired by TCP's tcp_collapse() which solves a similar problem, add
virtio_transport_collapse_rx_queue() that walks the receive queue and
re-copies data into compact linear skbs to reduce the overhead.
The collapse is triggered from virtio_transport_recv_enqueue() when
virtio_transport_inc_rx_pkt() fails. A pre-scan counts the eligible bytes
to size each allocation precisely, avoiding waste for isolated small
packets. Partially consumed skbs are kept as-is to preserve
buf_used/fwd_cnt accounting, EOM-marked skbs to maintain SEQPACKET
message boundaries, and skbs already larger than the collapse target
because they already have a good data-to-overhead ratio.
[1] https://github.com/stefano-garzarella/iperf-vsock
Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue")
Cc: stable@vger.kernel.org
Reported-by: Brien Oberstein <brienpub@gmail.com>
Closes: https://lore.kernel.org/netdev/618701dd023e$063de350$12b9a9f0$@gmail.com/
Tested-by: Brien Oberstein <brienpub@gmail.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 148 +++++++++++++++++++++++-
1 file changed, 146 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 09475007165b..304ea424995d 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -420,6 +420,137 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
return ret;
}
+static bool virtio_transport_can_collapse(struct sk_buff *skb,
+ unsigned int size)
+{
+ /* skbs that are partially consumed, mark a SEQPACKET message boundary,
+ * or are already large enough should not be collapsed: they either
+ * need special accounting, carry protocol state, or already have a
+ * good data-to-overhead ratio.
+ */
+ if (VIRTIO_VSOCK_SKB_CB(skb)->offset)
+ return false;
+ if (le32_to_cpu(virtio_vsock_hdr(skb)->flags) & VIRTIO_VSOCK_SEQ_EOM)
+ return false;
+ if (skb->len >= size)
+ return false;
+ return true;
+}
+
+/* Iterate through the packets in the queue starting from the current skb to
+ * count the number of bytes we can collapse.
+ */
+static unsigned int
+virtio_transport_collapse_size(struct sk_buff *skb,
+ struct sk_buff_head *queue,
+ unsigned int max_size)
+{
+ unsigned int target = skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset;
+
+ while ((skb = skb_peek_next(skb, queue)) &&
+ virtio_transport_can_collapse(skb, max_size)) {
+ unsigned int len = skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset;
+
+ if (len > max_size - target)
+ return target;
+
+ target += len;
+ }
+
+ return target;
+}
+
+/* Called under lock_sock when skb overhead exceeds the budget. */
+static void virtio_transport_collapse_rx_queue(struct virtio_vsock_sock *vvs)
+{
+ /* Use the same linear allocation threshold as virtio_vsock_alloc_skb()
+ * to avoid adding pressure on the page allocator.
+ */
+ unsigned int collapse_max = SKB_MAX_ORDER(VIRTIO_VSOCK_SKB_HEADROOM,
+ PAGE_ALLOC_COSTLY_ORDER);
+ struct sk_buff *skb, *next_skb, *new_skb = NULL;
+ struct sk_buff_head new_queue;
+
+ __skb_queue_head_init(&new_queue);
+
+ skb_queue_walk_safe(&vvs->rx_queue, skb, next_skb) {
+ struct virtio_vsock_hdr *hdr = virtio_vsock_hdr(skb);
+ u32 src_off = VIRTIO_VSOCK_SKB_CB(skb)->offset;
+ u32 src_len = skb->len - src_off;
+ bool keep = false;
+
+ if (!virtio_transport_can_collapse(skb, collapse_max)) {
+ /* Finalize pending collapsed skb to preserve packet
+ * ordering.
+ */
+ if (new_skb) {
+ __skb_queue_tail(&new_queue, new_skb);
+ new_skb = NULL;
+ }
+ keep = true;
+ goto next;
+ }
+
+ /* Finalize if this packet won't fit in the remaining tailroom,
+ * so we can allocate a right-sized new_skb.
+ */
+ if (new_skb && src_len > skb_tailroom(new_skb)) {
+ __skb_queue_tail(&new_queue, new_skb);
+ new_skb = NULL;
+ }
+
+ if (!new_skb) {
+ unsigned int alloc_size;
+
+ alloc_size = virtio_transport_collapse_size(skb, &vvs->rx_queue,
+ collapse_max);
+
+ /* Only this skb's data is eligible, nothing to merge
+ * with. Keep as-is.
+ */
+ if (alloc_size <= src_len) {
+ keep = true;
+ goto next;
+ }
+
+ new_skb = virtio_vsock_alloc_linear_skb(alloc_size +
+ VIRTIO_VSOCK_SKB_HEADROOM, GFP_KERNEL);
+ if (!new_skb)
+ goto out;
+
+ memcpy(virtio_vsock_hdr(new_skb), hdr,
+ sizeof(struct virtio_vsock_hdr));
+ virtio_vsock_hdr(new_skb)->len = 0;
+ }
+
+ /* Cannot fail since src_off/src_len are within bounds, but if
+ * it does, discard new_skb to avoid queuing corrupted data.
+ */
+ if (WARN_ON_ONCE(skb_copy_bits(skb, src_off,
+ skb_put(new_skb, src_len),
+ src_len))) {
+ kfree_skb(new_skb);
+ new_skb = NULL;
+ goto out;
+ }
+
+ le32_add_cpu(&virtio_vsock_hdr(new_skb)->len, src_len);
+ virtio_vsock_hdr(new_skb)->flags |= hdr->flags;
+
+next:
+ __skb_unlink(skb, &vvs->rx_queue);
+ if (keep)
+ __skb_queue_tail(&new_queue, skb);
+ else
+ consume_skb(skb);
+ }
+out:
+ if (new_skb)
+ __skb_queue_tail(&new_queue, new_skb);
+
+ skb_queue_splice(&new_queue, &vvs->rx_queue);
+}
+
static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
u32 len)
{
@@ -1363,8 +1494,21 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
spin_lock_bh(&vvs->rx_lock);
can_enqueue = virtio_transport_inc_rx_pkt(vvs, len);
- if (!can_enqueue)
- goto out;
+ if (!can_enqueue) {
+ /* Try to collapse the receive queue to reduce skb overhead and
+ * make room for this packet.
+ * Unlock rx_lock since the collapse may sleep or, in any case,
+ * take some time to collapse the skbs, but this is safe, since
+ * sk_lock is held by caller so no one else can enqueue or
+ * dequeue.
+ */
+ spin_unlock_bh(&vvs->rx_lock);
+ virtio_transport_collapse_rx_queue(vvs);
+ spin_lock_bh(&vvs->rx_lock);
+ can_enqueue = virtio_transport_inc_rx_pkt(vvs, len);
+ if (!can_enqueue)
+ goto out;
+ }
if (le32_to_cpu(hdr->flags) & VIRTIO_VSOCK_SEQ_EOM)
vvs->msg_count++;
--
2.54.0
^ permalink raw reply related
* [PATCH net 0/2] vsock/virtio: collapse receive queue under memory pressure
From: Stefano Garzarella @ 2026-06-26 13:48 UTC (permalink / raw)
To: netdev
Cc: Jason Wang, Jakub Kicinski, Paolo Abeni, Michael S. Tsirkin, kvm,
virtualization, Xuan Zhuo, Eric Dumazet, Simon Horman,
Stefano Garzarella, linux-kernel, Stefan Hajnoczi,
David S. Miller, Eugenio Pérez
This series contains a patch (the first one) that is part of work I'm
doing to improve the tracking of memory used by AF_VSOCK sockets.
The second patch is a test for our suite that highlights the issue.
Since Brien reported an issue with his environment (based on Linux 6.12.y)
related to the work I’m doing, I extracted this patch and tried to make it
as easy as possible to backport. Brien tested it by backporting it to
6.12.y, which now contains the backport of the 059b7dbd20a6
("vsock/virtio: fix potential unbounded skb queue").
This patch primarily fixes STREAM sockets, but also partially fixes
SEQPACKET (with the exception of EOMs, which are kept in separate skbs to
avoid overcomplicating the code).
The rest of the work, I feel, is more net-next material and still needs
some work to be completed.
Thanks,
Stefano
Stefano Garzarella (2):
vsock/virtio: collapse receive queue under memory pressure
vsock/test: add test for small packets under pressure
net/vmw_vsock/virtio_transport_common.c | 148 +++++++++++++++++++++++-
tools/testing/vsock/vsock_test.c | 87 ++++++++++++++
2 files changed, 233 insertions(+), 2 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v4 6/8] media: virtio: Add virtio_media_driver
From: Markus Elfring @ 2026-06-26 13:33 UTC (permalink / raw)
To: Alexandre Courbot, Brian Daniels, linux-media, virtualization,
Mauro Carvalho Chehab
Cc: LKML, Alexandre Courbot, Albert Esteve, Alistair Delva,
Changyeon Jo, Daniel Almeida, Eugenio Pérez, Gurchetan Singh,
Hans Verkuil, Jason Wang, Michael S. Tsirkin, Nicolas Dufresne,
Xuan Zhuo
In-Reply-To: <20260622204343.1994418-7-briandaniels@google.com>
…
> +++ b/drivers/media/virtio/virtio_media_driver.c
> @@ -0,0 +1,959 @@
…
> +static void virtio_media_session_free(struct virtio_media *vv,
> + struct virtio_media_session *session)
> +{
> + int i;
> +
> + mutex_lock(&vv->sessions_lock);
> + list_del(&session->list);
> + mutex_unlock(&vv->sessions_lock);
…
Under which circumstances would you become interested to apply a statement
like “guard(mutex)(&vv->sessions_lock);”?
https://elixir.bootlin.com/linux/v7.1.1/source/include/linux/mutex.h#L253
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2] vhost/net: fix clear_user start address in VHOST_GET_FEATURES_ARRAY
From: Eugenio Perez Martin @ 2026-06-26 11:31 UTC (permalink / raw)
To: rom.wang
Cc: Michael S . Tsirkin, Jason Wang, Paolo Abeni, kvm, virtualization,
netdev, linux-kernel, Yufeng Wang
In-Reply-To: <20260626070438.59149-1-r4o5m6e8o@163.com>
On Fri, Jun 26, 2026 at 9:05 AM rom.wang <r4o5m6e8o@163.com> wrote:
>
> From: Yufeng Wang <wangyufeng@kylinos.cn>
>
> The clear_user() call in VHOST_GET_FEATURES_ARRAY incorrectly starts
> at argp, which is the beginning of the features array, overwriting the
> data just written by copy_to_user(). It should start after the copied
> elements at argp + copied * sizeof(u64) to only zero the trailing
> unused space.
>
> Use size_mul() for both the offset and length calculations so the
> arithmetic stays consistent with the surrounding code and remains
> overflow-safe.
>
> Fixes: 333c515d1896 ("vhost-net: allow configuring extended features")
> Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn>
>
> ---
> Changes in v2:
> - Use size_mul() for the offset calculation as well, per review feedback.
>
> Link to v1: https://lore.kernel.org/all/20260526080336.61296-1-r4o5m6e8o@163.com/
>
> Note:
> Thank you for your review and suggestions.
>
> I tried to add a switch in tools/virtio/vhost_net_test.c.
> The switch is meant to use VHOST_GET_FEATURES_ARRAY and
> VHOST_SET_FEATURES_ARRAY instead of the legacy versions.
>
> However, when I ran `make virtio` in the tools directory,
> the build failed with an error: missing asm/percpu_types.h.
> I fixed that error, but then another error appeared.
>
> Would it be acceptable to postpone the submission of
> this test case until I have sorted out all the build
> errors?
> ---
> drivers/vhost/net.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 77b59f49bddb..4b963dafa233 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -1784,7 +1784,8 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
> return -EFAULT;
>
> /* Zero the trailing space provided by user-space, if any */
> - if (clear_user(argp, size_mul(count - copied, sizeof(u64))))
> + if (clear_user(argp + size_mul(copied, sizeof(u64)),
> + size_mul(count - copied, sizeof(u64))))
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Thanks!
> return -EFAULT;
> return 0;
> case VHOST_SET_FEATURES_ARRAY:
> --
> 2.34.1
>
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Weißschuh @ 2026-06-26 11:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <87echtk24a.ffs@fw13>
On Fri, Jun 26, 2026 at 12:49:41PM +0200, Thomas Gleixner wrote:
> On Fri, Jun 26 2026 at 10:48, Thomas Weißschuh wrote:
> > On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
> > (...)
> >
> >> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
> >> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
> >> tkd = &tk_core;
> >> offs = &tk_core.timekeeper.offs_boot;
> >> break;
> >> + case CLOCK_AUX ... CLOCK_AUX_LAST:
> >> + tkd = aux_get_tk_data(clock_id);
> >> + if (!tkd)
> >> + return false;
> >> + offs = &tkd->timekeeper.offs_aux;
> >> + break;
> >
> > 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> > are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
>
> AUX clocks are independent in the first place and the MONORAW part is
> the "MONORAW" related to the AUX clock itself.
>
> > Instead 'monoraw' should be computed based on 'tk_core'.
> > Which then also requires the sequence locking of 'tk_core'.
>
> No. From a PTP and steering point of view you want the "raw" value which
> is related to the AUX clock itself and not the global one.
Ack.
However the kdocs call it 'CLOCK_MONOTONIC_RAW'. Can we clean this up?
> The global MONORAW and the AUX clock MONORAW are related obviously as
> they share the same conversion factors.
>
> MONORAW(AUX$N) = MONORAW(GLOBAL) + OFFSET(AUX$N)
>
> We don't have that information anywhere right now and we might want to
> expose it to allow user space a proper correlation, but that's an
> orthogonal problem.
>
> From a PTP/steering point of view the code is correct as is.
Thanks for the clarifications.
Thomas
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: David Woodhouse @ 2026-06-26 10:51 UTC (permalink / raw)
To: Thomas Weißschuh, Thomas Gleixner
Cc: LKML, Miroslav Lichvar, John Stultz, Stephen Boyd,
Anna-Maria Behnsen, Frederic Weisbecker, Arthur Kiyanovski,
Rodolfo Giometti, Vincent Donnefort, Marc Zyngier, Oliver Upton,
kvmarm, Oliver Upton, Richard Cochran, netdev, Takashi Iwai,
Miri Korenblit, Johannes Berg, Jacob Keller, Tony Nguyen,
Saeed Mahameed, Peter Hilber, Michael S. Tsirkin, virtualization,
linux-wireless, linux-sound
In-Reply-To: <20260626103359-66ab2b54-d36f-416b-94a4-3f3708dccced@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]
On Fri, 2026-06-26 at 10:48 +0200, Thomas Weißschuh wrote:
> 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
> Instead 'monoraw' should be computed based on 'tk_core'.
> Which then also requires the sequence locking of 'tk_core'.
>
> As you know I have a series which unifies the locking between the
> different timekeepers. Maybe we revert this patch for 7.2 and I send
> a fixed variant including the prerequisites for 7.3.
>
> (The same goes for get_device_system_crosststamp())
No fundamental objection from me... but does it matter in practice?
Is it even reachable?
I think the only way these functions can end up being invoked for aux
clocks is via PTP_SYS_OFFSET_EXTENDED, which since commit a6d799608e6
("ptp: Switch to ktime_get_snapshot_id() for pre/post timestamps") and
some other driver-specific changes in this series, can now invoke them
with the user-requested clockid.
But those callers *only* care about ::systime, don't they? So the
problem never arises because there's no code path in which anything
actually cares about ::monoraw for AUX clocks.
If we back out the handling of AUX clocks in ktime_get_snapshot_id()
we'd have to roll back much of that other plumbing too. If we *just*
remove the 'case CLOCK_AUX ... CLOCK_AUX_LAST' hunk, we'd end up with
users being able to trigger the 'default: WARN_ON_ONCE(1)' which
follows.
So while you're right, I *think* it's harmless in practice and
reverting it safely is slightly more complex than it seems at first
glance?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Gleixner @ 2026-06-26 10:49 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260626103359-66ab2b54-d36f-416b-94a4-3f3708dccced@linutronix.de>
On Fri, Jun 26 2026 at 10:48, Thomas Weißschuh wrote:
> On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
> (...)
>
>> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
>> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
>> tkd = &tk_core;
>> offs = &tk_core.timekeeper.offs_boot;
>> break;
>> + case CLOCK_AUX ... CLOCK_AUX_LAST:
>> + tkd = aux_get_tk_data(clock_id);
>> + if (!tkd)
>> + return false;
>> + offs = &tkd->timekeeper.offs_aux;
>> + break;
>
> 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
AUX clocks are independent in the first place and the MONORAW part is
the "MONORAW" related to the AUX clock itself.
> Instead 'monoraw' should be computed based on 'tk_core'.
> Which then also requires the sequence locking of 'tk_core'.
No. From a PTP and steering point of view you want the "raw" value which
is related to the AUX clock itself and not the global one.
The global MONORAW and the AUX clock MONORAW are related obviously as
they share the same conversion factors.
MONORAW(AUX$N) = MONORAW(GLOBAL) + OFFSET(AUX$N)
We don't have that information anywhere right now and we might want to
expose it to allow user space a proper correlation, but that's an
orthogonal problem.
From a PTP/steering point of view the code is correct as is.
Thanks,
tglx
^ permalink raw reply
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Weißschuh @ 2026-06-26 8:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, David Woodhouse, Miroslav Lichvar, John Stultz,
Stephen Boyd, Anna-Maria Behnsen, Frederic Weisbecker,
Arthur Kiyanovski, Rodolfo Giometti, Vincent Donnefort,
Marc Zyngier, Oliver Upton, kvmarm, Oliver Upton, Richard Cochran,
netdev, Takashi Iwai, Miri Korenblit, Johannes Berg, Jacob Keller,
Tony Nguyen, Saeed Mahameed, Peter Hilber, Michael S. Tsirkin,
virtualization, linux-wireless, linux-sound
In-Reply-To: <20260526171223.374814973@kernel.org>
On Tue, May 26, 2026 at 07:14:13PM +0200, Thomas Gleixner wrote:
(...)
> static inline void tk_update_aux_offs(struct timekeeper *tk, ktime_t offs)
> @@ -1218,6 +1223,12 @@ bool ktime_get_snapshot_id(struct system
> tkd = &tk_core;
> offs = &tk_core.timekeeper.offs_boot;
> break;
> + case CLOCK_AUX ... CLOCK_AUX_LAST:
> + tkd = aux_get_tk_data(clock_id);
> + if (!tkd)
> + return false;
> + offs = &tkd->timekeeper.offs_aux;
> + break;
'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
Instead 'monoraw' should be computed based on 'tk_core'.
Which then also requires the sequence locking of 'tk_core'.
As you know I have a series which unifies the locking between the
different timekeepers. Maybe we revert this patch for 7.2 and I send
a fixed variant including the prerequisites for 7.3.
(The same goes for get_device_system_crosststamp())
> default:
> WARN_ON_ONCE(1);
> return false;
> @@ -1228,6 +1239,10 @@ bool ktime_get_snapshot_id(struct system
> do {
> seq = read_seqcount_begin(&tkd->seq);
>
> + /* Aux clocks can be invalid */
> + if (!tk->clock_valid)
> + return false;
> +
> now = tk_clock_read(&tk->tkr_mono);
> systime_snapshot->cs_id = tk->tkr_mono.clock->id;
> systime_snapshot->cs_was_changed_seq = tk->cs_was_changed_seq;
>
^ permalink raw reply
* [PATCH v2] vhost/net: fix clear_user start address in VHOST_GET_FEATURES_ARRAY
From: rom.wang @ 2026-06-26 7:04 UTC (permalink / raw)
To: Michael S . Tsirkin, Jason Wang, Eugenio Pérez, Paolo Abeni,
kvm, virtualization, netdev
Cc: linux-kernel, Yufeng Wang
From: Yufeng Wang <wangyufeng@kylinos.cn>
The clear_user() call in VHOST_GET_FEATURES_ARRAY incorrectly starts
at argp, which is the beginning of the features array, overwriting the
data just written by copy_to_user(). It should start after the copied
elements at argp + copied * sizeof(u64) to only zero the trailing
unused space.
Use size_mul() for both the offset and length calculations so the
arithmetic stays consistent with the surrounding code and remains
overflow-safe.
Fixes: 333c515d1896 ("vhost-net: allow configuring extended features")
Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn>
---
Changes in v2:
- Use size_mul() for the offset calculation as well, per review feedback.
Link to v1: https://lore.kernel.org/all/20260526080336.61296-1-r4o5m6e8o@163.com/
Note:
Thank you for your review and suggestions.
I tried to add a switch in tools/virtio/vhost_net_test.c.
The switch is meant to use VHOST_GET_FEATURES_ARRAY and
VHOST_SET_FEATURES_ARRAY instead of the legacy versions.
However, when I ran `make virtio` in the tools directory,
the build failed with an error: missing asm/percpu_types.h.
I fixed that error, but then another error appeared.
Would it be acceptable to postpone the submission of
this test case until I have sorted out all the build
errors?
---
drivers/vhost/net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 77b59f49bddb..4b963dafa233 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1784,7 +1784,8 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
return -EFAULT;
/* Zero the trailing space provided by user-space, if any */
- if (clear_user(argp, size_mul(count - copied, sizeof(u64))))
+ if (clear_user(argp + size_mul(copied, sizeof(u64)),
+ size_mul(count - copied, sizeof(u64))))
return -EFAULT;
return 0;
case VHOST_SET_FEATURES_ARRAY:
--
2.34.1
^ permalink raw reply related
* Re: [syzbot] [net?] BUG: soft lockup in perf_event_open (2)
From: syzbot @ 2026-06-26 6:20 UTC (permalink / raw)
To: acme, adrian.hunter, alexander.shishkin, andrew, davem, edumazet,
eperezma, irogers, james.clark, jasowang, jolsa, kuba,
linux-kernel, linux-perf-users, mark.rutland, mingo, mst,
namhyung, netdev, pabeni, peterz, syzkaller-bugs, virtualization,
xuanzhuo
In-Reply-To: <69ad01b6.050a0220.310d8.0006.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 4edcdefd4083 Merge tag 'bpf-fixes' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16da941e580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3c3d59be33cf7e9a
dashboard link: https://syzkaller.appspot.com/bug?extid=e04801269a8f6321dd79
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=164054ea580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-4edcdefd.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/01cc5d298db0/vmlinux-4edcdefd.xz
kernel image: https://storage.googleapis.com/syzbot-assets/59e4cf862ca3/bzImage-4edcdefd.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e04801269a8f6321dd79@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: (detected by 0, t=10502 jiffies, g=61569, q=162 ncpus=1)
rcu: All QSes seen, last rcu_preempt kthread activity 10502 (4294967357-4294956855), jiffies_till_next_fqs=1, root ->qsmask 0x0
rcu: rcu_preempt kthread starved for 10502 jiffies! g61569 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task stack:27464 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x17d9/0x56c0 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0x164/0x2b0 kernel/sched/core.c:7326
schedule_timeout+0x152/0x2c0 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x30c/0x11f0 kernel/rcu/tree.c:2123
rcu_gp_kthread+0x9e/0x2b0 kernel/rcu/tree.c:2325
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: Stack dump where RCU GP kthread last ran:
CPU: 0 UID: 0 PID: 5714 Comm: syz.3.20 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
RIP: 0010:unwind_next_frame+0x19ae/0x2550 arch/x86/kernel/unwind_orc.c:677
Code: e8 03 42 0f b6 04 20 84 c0 0f 85 b6 0a 00 00 4c 89 e8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 c5 0a 00 00 48 0f bf 03 49 01 c0 <49> 8d 56 40 4c 89 f7 4c 89 c6 e8 33 0e 00 00 84 c0 0f 84 4e 01 00
RSP: 0018:ffffc900000074e0 EFLAGS: 00000283
RAX: fffffffffffffff0 RBX: ffffffff91709a28 RCX: 0000000000000000
RDX: ffffffff91709a2a RSI: 0000000000000008 RDI: ffffc900000075e8
RBP: 1ffffffff22e1345 R08: ffffc900034df7c8 R09: 0000000000000000
R10: ffffc900000075d8 R11: fffff52000000ebd R12: dffffc0000000000
R13: ffffffff91709a29 R14: ffffc90000007588 R15: ffffc900000075d0
FS: 0000555594cee500(0000) GS:ffff88808c81b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5209872780 CR3: 0000000035426000 CR4: 0000000000352ef0
Call Trace:
<IRQ>
arch_stack_walk+0x11b/0x150 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0xa9/0x100 kernel/stacktrace.c:122
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2705 [inline]
slab_free mm/slub.c:6405 [inline]
kmem_cache_free+0x182/0x650 mm/slub.c:6532
kfree_skb_reason include/linux/skbuff.h:1323 [inline]
kfree_skb include/linux/skbuff.h:1332 [inline]
hsr_forward_skb+0x1a27/0x28c0 net/hsr/hsr_forward.c:753
send_hsr_supervision_frame+0x733/0xcf0 net/hsr/hsr_device.c:364
hsr_announce+0x1db/0x370 net/hsr/hsr_device.c:421
call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x652/0x8b0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
handle_softirqs+0x225/0x840 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xca/0x220 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1062
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
RIP: 0010:finish_task_switch+0x417/0xc60 kernel/sched/core.c:5361
Code: 04 00 00 41 c7 84 24 20 0e 00 00 00 00 00 00 0f 1f 44 00 00 49 83 c4 48 4c 89 e7 e8 a3 5a 23 0a e8 6e bc 39 00 fb 4c 8b 65 c8 <49> 8d bc 24 f8 16 00 00 48 89 f8 48 c1 e8 03 42 0f b6 04 30 84 c0
RSP: 0018:ffffc900034df880 EFLAGS: 00000206
RAX: 00000000000009c3 RBX: ffff88801fc3bf20 RCX: 0000000080000001
RDX: 0000000000000006 RSI: ffffffff8dfe613c RDI: ffffffff8c2aaf80
RBP: ffffc900034df8d0 R08: ffffffff9032f8f7 R09: 1ffffffff2065f1e
R10: dffffc0000000000 R11: fffffbfff2065f1f R12: ffff88803292a540
R13: ffff88801fc3bee8 R14: dffffc0000000000 R15: 1ffff11003f877e4
context_switch kernel/sched/core.c:5513 [inline]
__schedule+0x17e1/0x56c0 kernel/sched/core.c:7234
preempt_schedule_common+0x82/0xd0 kernel/sched/core.c:7413
preempt_schedule_thunk+0x16/0x40 arch/x86/entry/thunk.S:12
__mutex_lock_common kernel/locking/mutex.c:656 [inline]
__mutex_lock+0x321/0x1550 kernel/locking/mutex.c:821
__do_sys_perf_event_open kernel/events/core.c:14249 [inline]
__se_sys_perf_event_open+0x1984/0x1d40 kernel/events/core.c:13881
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f520999ce59
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:00007ffd9f0e1458 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
RAX: ffffffffffffffda RBX: 00007f5209c15fa0 RCX: 00007f520999ce59
RDX: bfffffffffffffff RSI: 0000000000000000 RDI: 0000200000000180
RBP: 00007f5209a32e6f R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000246 R12: 0000000000000000
R13: 00007f5209c15fac R14: 00007f5209c15fa0 R15: 00007f5209c15fa0
</TASK>
---
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.
^ permalink raw reply
* [PATCH] MAINTAINERS: Update Jason Wang's email address
From: Jason Wang @ 2026-06-26 2:20 UTC (permalink / raw)
To: mst, virtualization, netdev; +Cc: eperezma, kvm, linux-kernel, Jason Wang
I will use jasowangio@gmail.com for future review and discussion.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
MAINTAINERS | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..40d9641cbc7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27520,7 +27520,7 @@ F: drivers/net/ethernet/dec/tulip/
TUN/TAP DRIVER
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
S: Maintained
W: http://vtun.sourceforge.net/tun
F: Documentation/networking/tuntap.rst
@@ -28512,7 +28512,7 @@ F: include/uapi/linux/virtio_balloon.h
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
R: Eugenio Pérez <eperezma@redhat.com>
@@ -28541,7 +28541,7 @@ F: include/uapi/linux/virtio_console.h
VIRTIO CORE
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: virtualization@lists.linux.dev
@@ -28619,7 +28619,7 @@ F: include/uapi/linux/virtio_gpu.h
VIRTIO HOST (VHOST)
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: kvm@vger.kernel.org
L: virtualization@lists.linux.dev
@@ -28634,7 +28634,7 @@ F: kernel/vhost_task.c
VIRTIO HOST (VHOST-SCSI)
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
M: Mike Christie <michael.christie@oracle.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
@@ -28674,7 +28674,7 @@ F: include/uapi/linux/virtio_mem.h
VIRTIO NET DRIVER
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: netdev@vger.kernel.org
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] vdpa_sim: hold iommu_lock across dma_unmap passthrough transition
From: Xiong Weimin @ 2026-06-26 2:05 UTC (permalink / raw)
To: Jason Wang, Michael S . Tsirkin
Cc: netdev, virtualization, linux-kernel, Xiong Weimin
In-Reply-To: <20260626020545.607600-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
vdpasim_dma_map() updates the IOTLB and the passthrough (iommu_pt)
state under iommu_lock. vdpasim_dma_unmap() clears iommu_pt and
resets the IOTLB before taking iommu_lock, then deletes the mapping
while holding the lock.
A concurrent dma_map(), dma_unmap(), or reset path that also touches
the same address space can therefore observe or modify the IOTLB and
iommu_pt state without consistent locking.
Perform the passthrough transition and range deletion under the same
iommu_lock scope, matching dma_map().
Tested-on: openEuler VM (6.16.8, /usr/src/linux-6.16.8)
Tested-by: Xiong Weimin <xiongweimin@kylinos.cn>
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -736,12 +736,11 @@ static int vdpasim_dma_unmap(struct vdpa_device *vdpa, unsigned int asid,
if (asid >= vdpasim->dev_attr.nas)
return -EINVAL;
+ spin_lock(&vdpasim->iommu_lock);
if (vdpasim->iommu_pt[asid]) {
vhost_iotlb_reset(&vdpasim->iommu[asid]);
vdpasim->iommu_pt[asid] = false;
}
-
- spin_lock(&vdpasim->iommu_lock);
vhost_iotlb_del_range(&vdpasim->iommu[asid], iova, iova + size - 1);
spin_unlock(&vdpasim->iommu_lock);
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] vdpa_sim: clear pending_kick on device reset
From: Xiong Weimin @ 2026-06-26 2:05 UTC (permalink / raw)
To: Jason Wang, Michael S . Tsirkin
Cc: netdev, virtualization, linux-kernel, Xiong Weimin
In-Reply-To: <20260626020545.607600-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
vdpasim_kick_vq() sets pending_kick when a virtqueue is kicked while
the device is suspended (!running but DRIVER_OK). vdpasim_resume()
later replays kicks for all virtqueues when pending_kick is set.
vdpasim_do_reset() clears running and status but leaves pending_kick
unchanged. If a kick is deferred during suspend and the device is
reset before resume, a later resume can spuriously kick every
virtqueue even though no new work was queued after reset.
Clear pending_kick in vdpasim_do_reset() together with the other
device state that must not survive a reset.
Tested-on: openEuler VM (6.16.8, /usr/src/linux-6.16.8)
Tested-by: Xiong Weimin <xiongweimin@kylinos.cn>
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -161,6 +161,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim, u32 flags)
}
vdpasim->running = false;
+ vdpasim->pending_kick = false;
spin_unlock(&vdpasim->iommu_lock);
vdpasim->features = 0;
--
2.43.0
^ permalink raw reply
* [PATCH 0/2] vdpa_sim: fix suspend/reset and dma_unmap locking
From: Xiong Weimin @ 2026-06-26 2:05 UTC (permalink / raw)
To: Jason Wang, Michael S . Tsirkin
Cc: netdev, virtualization, linux-kernel, Xiong Weimin
From: Xiong Weimin <xiongweimin@kylinos.cn>
This series fixes two independent issues in the vDPA simulator:
1. Clear pending_kick on device reset so a deferred kick from a
suspended device cannot be replayed after reset/re-init.
2. Hold iommu_lock across the full dma_unmap() path, including the
passthrough-to-custom mapping transition, matching dma_map().
Both patches tested on an openEuler VM running kernel 6.16.8: built
vdpa_sim.ko from /usr/src/linux-6.16.8 and reloaded vdpa_sim /
vdpa_sim_net successfully.
Xiong Weimin (2):
vdpa_sim: clear pending_kick on device reset
vdpa_sim: hold iommu_lock across dma_unmap passthrough transition
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v4 1/8] media: virtio: Add protocol
From: Bryan O'Donoghue @ 2026-06-26 0:50 UTC (permalink / raw)
To: Brian Daniels, Mauro Carvalho Chehab
Cc: acourbot, adelva, aesteve, changyeon, daniel.almeida, eperezma,
gnurou, gurchetansingh, hverkuil, jasowang, linux-kernel,
linux-media, mst, nicolas.dufresne, virtualization, xuanzhuo
In-Reply-To: <20260625202412.2986772-1-briandaniels@google.com>
On 25/06/2026 21:24, Brian Daniels wrote:
> I'm not an expert here, but taking a look at those files, the vast majority of
> those reserved fields appear to be padding to ensure the struct has 64-bit
> alignment, which matches the use here in virtio-media as well.
>
> virtio_pci appears to be the only device that explicitly states the
> reserved bytes are for future extensions. Unless there's a good a reason to
> expect a future use case where more space is needed, I would prefer to not add
> more at this time.
I'm querying why just the one though ? Why not say four ?
Perhaps something you could address in your commit log.
---
bod
^ permalink raw reply
* Re: [PATCH v4 2/8] media: virtio: Add virtio-media driver structs and function declarations
From: Brian Daniels @ 2026-06-25 20:25 UTC (permalink / raw)
To: Bryan O'Donoghue, Mauro Carvalho Chehab
Cc: Brian Daniels, acourbot, adelva, aesteve, changyeon,
daniel.almeida, eperezma, gnurou, gurchetansingh, hverkuil,
jasowang, linux-kernel, linux-media, mst, nicolas.dufresne,
virtualization, xuanzhuo
In-Reply-To: <ce63d29a-8c76-4a3d-ad8f-144f8b709cfa@kernel.org>
> > +extern char *virtio_media_driver_name;
> > +extern bool virtio_media_allow_userptr;
>
> This looks a bit funny to me - why do you have externs in your header ?
>
> ➜ grep -r virtio * | grep extern
> arch/mips/include/asm/mach-loongson64/builtin_dtbs.h:extern u32
> __dtb_loongson64v_4core_virtio_begin[];
> Documentation/virt/kvm/api.rst: - virtio external interrupt; external
> interrupt
> drivers/gpu/drm/virtio/virtgpu_drv.h:extern struct drm_ioctl_desc
> virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
> drivers/net/wireless/virtual/mac80211_hwsim.c:extern int
> hwsim_tx_virtio(struct mac80211_hwsim_data *data,
> include/linux/virtio_anchor.h:extern bool
> (*virtio_check_mem_acc_cb)(struct virtio_device *dev);
You're command will only return lines that contain both `virtio` and `extern`.
If you instead wanted to find all header files that contain externs, I believe
you would want something like:
find -type f -name '*.h' | xargs grep extern
When I run this I find many examples of `extern` in header files.
That all being said, the reason the `extern`s are in the header file is so
files that include said header file can access those variables. In this case,
these variables are used for different module parameters. We may be
removing them though, check the other discussion thread.
^ permalink raw reply
* Re: [PATCH v4 1/8] media: virtio: Add protocol
From: Brian Daniels @ 2026-06-25 20:24 UTC (permalink / raw)
To: Bryan O'Donoghue, Mauro Carvalho Chehab
Cc: Brian Daniels, acourbot, adelva, aesteve, changyeon,
daniel.almeida, eperezma, gnurou, gurchetansingh, hverkuil,
jasowang, linux-kernel, linux-media, mst, nicolas.dufresne,
virtualization, xuanzhuo
In-Reply-To: <4b2078a0-9422-467b-b167-9a0b5444f18d@kernel.org>
> > + u32 __reserved;
>
> Knowing ~ nothing about virtio with ~ no experience of it I'll offer up
> a question/statement anyway.
>
> Aren't your reservations here a bit conservative ? Would you not be well
> advised to reserve a bit more space per other virtio protocols ?
>
> ➜ grep reserved ./include/uapi/linux/*.h | grep virtio
> ./include/uapi/linux/virtio_balloon.h: * __u8 reserved[6];
> ./include/uapi/linux/virtio_balloon.h: * In other words, add explicit
> reserved fields to align field and
> ./include/uapi/linux/virtio_blk.h: __u8 reserved[38];
> ./include/uapi/linux/virtio_blk.h: __u8 reserved[56];
> ./include/uapi/linux/virtio_config.h: * VIRTIO_TRANSPORT_F_END are
> reserved for the transport
> ./include/uapi/linux/virtio_crypto.h: __le32 reserved;
> ./include/uapi/linux/virtio_i2c.h: * Copyright (c) 2021 Intel
> Corporation. All rights reserved.
> ./include/uapi/linux/virtio_input.h: __u8 reserved[5];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[3];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[3];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[3];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[4];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[8];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[4];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[3];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[64];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved[3];
> ./include/uapi/linux/virtio_iommu.h: __u8
> reserved2[4];
> ./include/uapi/linux/virtio_net.h: __le16 reserved[4];
> ./include/uapi/linux/virtio_net.h: __le16 reserved;
> ./include/uapi/linux/virtio_net.h: __le16 reserved[3];
> ./include/uapi/linux/virtio_net.h: __u8 reserved;
> ./include/uapi/linux/virtio_net.h: __le16 reserved1;
> ./include/uapi/linux/virtio_pcidev.h: * @VIRTIO_PCIDEV_OP_RESERVED:
> reserved to catch errors
> ./include/uapi/linux/virtio_pcidev.h: * @reserved: reserved
> ./include/uapi/linux/virtio_pcidev.h: __u16 reserved;
> ./include/uapi/linux/virtio_pci.h: * 2-65535 - reserved
> ./include/uapi/linux/virtio_pci.h: /* Unused, reserved for future
> extensions. */
> ./include/uapi/linux/virtio_pci.h: __u8 reserved1[12];
> ./include/uapi/linux/virtio_pci.h: /* Unused, reserved for future
> extensions. */
> ./include/uapi/linux/virtio_pci.h: __u8 reserved2[4];
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[7];
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[2];
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[7];
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[7];
> ./include/uapi/linux/virtio_pci.h: __u8 reserved;
> ./include/uapi/linux/virtio_pci.h: __le32 reserved;
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_pci.h: __le32 reserved;
> ./include/uapi/linux/virtio_pci.h: __le32 reserved;
> ./include/uapi/linux/virtio_pci.h: __le32 reserved;
> ./include/uapi/linux/virtio_pci.h: __u8 reserved[7];
> ./include/uapi/linux/virtio_rtc.h: * Copyright (c) 2024 Qualcomm
> Innovation Center, Inc. All rights reserved.
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[7];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[5];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[5];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[5];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[7];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[7];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[5];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[5];
> ./include/uapi/linux/virtio_rtc.h: __u8 reserved[6];
> ./include/uapi/linux/virtio_spi.h: * Copyright (C) 2025 Qualcomm
> Innovation Center, Inc. All rights reserved.
> ./include/uapi/linux/virtio_spi.h: * other bits are reserved as 0,
> 1-bit transfer is always supported.
> ./include/uapi/linux/virtio_spi.h: * other bits are reserved as 0,
> 1-bit transfer is always supported.
> ./include/uapi/linux/virtio_spi.h: * @reserved: for future use.
> ./include/uapi/linux/virtio_spi.h: __u8 reserved[3];+ u32
> __reserved;
I'm not an expert here, but taking a look at those files, the vast majority of
those reserved fields appear to be padding to ensure the struct has 64-bit
alignment, which matches the use here in virtio-media as well.
virtio_pci appears to be the only device that explicitly states the
reserved bytes are for future extensions. Unless there's a good a reason to
expect a future use case where more space is needed, I would prefer to not add
more at this time.
^ 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