* 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
* [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
* [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 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
* 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
* 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 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 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] 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] 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 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
* [PATCH v2] drm/qxl: fix use-after-free in qxl_irq_handler on PCI
From: Óscar Megía López @ 2026-06-27 10:54 UTC (permalink / raw)
To: Dave Airlie
Cc: Gerd Hoffmann, virtualization, spice-devel, linux-kernel-mentees,
Óscar Megía López
while :; do
echo [pci qxl id] > /sys/bus/pci/drivers/qxl/unbind
echo [pci qxl id] > /sys/bus/pci/drivers/qxl/bind
done
After a few seconds, it reports:
==================================================================
BUG: KASAN: slab-use-after-free in qxl_irq_handler+0x269/0x2b0
Read of size 8 at addr ffff888001c6cd48 by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
7.1.0-10963-g1a3746ccbb0a #31 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS Arch Linux 1.17.0-2-2 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0x4d/0x70
print_report+0x14b/0x4b0
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? profile_tick+0x56/0x90
? tick_nohz_handler+0x23c/0x5c0
kasan_report+0x117/0x140
? qxl_irq_handler+0x269/0x2b0
? qxl_irq_handler+0x269/0x2b0
? __pfx_qxl_irq_handler+0x10/0x10
qxl_irq_handler+0x269/0x2b0
? __pfx_qxl_irq_handler+0x10/0x10
? __pfx_qxl_irq_handler+0x10/0x10
__handle_irq_event_percpu+0x116/0x450
? __pfx__raw_spin_lock+0x10/0x10
handle_irq_event+0xa6/0x1c0
handle_fasteoi_irq+0x271/0xb10
? __pfx_handle_fasteoi_irq+0x10/0x10
__common_interrupt+0x60/0x130
common_interrupt+0x7a/0x90
</IRQ>
<TASK>
asm_common_interrupt+0x26/0x40
RIP: 0010:pv_native_safe_halt+0xf/0x20
Code: 42 de 00 c3 cc cc cc cc 0f 1f 00 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d a3 cf 20 00
fb f4 <c3> cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 66 90
90 90 90 90 90
RSP: 0018:ffffffffb8207e48 EFLAGS: 00000206
RAX: ffff8880b296f000 RBX: ffffffffb82146c0 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000067a04
RBP: fffffbfff70428d8 R08: ffffffffb7247e1d R09: 1ffff1100d846202
R10: ffffed100d846203 R11: ffffed100d846203 R12: 0000000000000000
R13: 0000000000000000 R14: 1ffffffff7040fcd R15: dffffc0000000000
? ct_kernel_exit.constprop.0+0x9d/0xc0
default_idle+0x9/0x10
o default_idle_call+0x37/0x60
do_idle+0x3a8/0x5d0
? __pfx___schedule+0x10/0x10
? __pfx_do_idle+0x10/0x10
cpu_startup_entry+0x4e/0x60
rest_init+0x11a/0x120
start_kernel+0x382/0x390
x86_64_start_reservations+0x24/0x30
x86_64_start_kernel+0xd6/0xe0
common_startup_64+0x13e/0x158
</TASK>
The qxl_pci_remove() function does not call free_irq(), allowing the IRQ
handler to fire after the device has been torn down, accessing freed
memory (qdev->ram_header, qdev->io_base).
I followed these steps to unload driver at link.
Added Disable the device from generating IRQs, Release the IRQ (free_irq())
at the start of qxl_pci_remove() to ensure no IRQs fire
after teardown begins.
Added at end Disable the device.
Fix: Added goto fini in ttm_device_fini() on error.
Bug: qxl_ttm_init never calls ttm_device_fini on failure
If qxl_ttm_init_mem_type() fails after ttm_device_init() succeeded,
ttm_glob_use_count stays incremented. All subsequent bind/unbind cycles
see refcount > 0 and skip ttm_pool_mgr_{init,fini}() entirely.
The global pool types are never finalized, and the list_lru_destroy fix
in ttm_pool_mgr_fini never runs.
Assisted-by: OpenCode:1.17.8-Big Pickle
Fixes: 48bd85808443 ("drm/qxl: Convert to Linux IRQ interfaces")
Signed-off-by: Óscar Megía López <megia.oscar@gmail.com>
Link: https://www.kernel.org/doc/html/latest/PCI/pci.html
---
drivers/gpu/drm/qxl/qxl_drv.c | 7 +++++++
drivers/gpu/drm/qxl/qxl_ttm.c | 8 ++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 1e6a2392d7c6..1613547c1856 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -154,12 +154,19 @@ static void
qxl_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct qxl_device *qdev = to_qxl(dev);
+
+ qdev->ram_header->int_mask = 0;
+ outb(0, qdev->io_base + QXL_IO_UPDATE_IRQ);
+ free_irq(pdev->irq, dev);
+ cancel_work_sync(&qdev->client_monitors_config_work);
drm_kms_helper_poll_fini(dev);
drm_dev_unregister(dev);
drm_atomic_helper_shutdown(dev);
if (pci_is_vga(pdev) && pdev->revision < 5)
vga_put(pdev, VGA_RSRC_LEGACY_IO);
+ pci_disable_device(pdev);
}
static void
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 5d495c4798a3..bdcc7560f3f1 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -207,13 +207,13 @@ int qxl_ttm_init(struct qxl_device *qdev)
r = qxl_ttm_init_mem_type(qdev, TTM_PL_VRAM, num_io_pages);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
- return r;
+ goto fini;
}
r = qxl_ttm_init_mem_type(qdev, TTM_PL_PRIV,
qdev->surfaceram_size / PAGE_SIZE);
if (r) {
DRM_ERROR("Failed initializing Surfaces heap.\n");
- return r;
+ goto fini;
}
DRM_INFO("qxl: %uM of VRAM memory size\n",
(unsigned int)qdev->vram_size / (1024 * 1024));
@@ -222,6 +222,10 @@ int qxl_ttm_init(struct qxl_device *qdev)
DRM_INFO("qxl: %uM of Surface memory size\n",
(unsigned int)qdev->surfaceram_size / (1024 * 1024));
return 0;
+
+fini:
+ ttm_device_fini(&qdev->mman.bdev);
+ return r;
}
void qxl_ttm_fini(struct qxl_device *qdev)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v6 04/12] nvdimm: virtio_pmem: stop allocating child flush bio
From: Li Chen @ 2026-06-27 12:44 UTC (permalink / raw)
To: Pankaj Gupta
Cc: Dan Williams, Vishal Verma, Alison Schofield, virtualization,
nvdimm, linux-kernel
In-Reply-To: <CAM9Jb+gzSrobPgH_nMPs+RsbhVP8jovpAQsC5syQKoLrtqnX=A@mail.gmail.com>
Hi Pankaj
---- On Thu, 25 Jun 2026 01:22:14 +0800 Pankaj Gupta <pankaj.gupta.linux@gmail.com> wrote ---
> > pmem_submit_bio() passes the parent bio to nvdimm_flush() for
> > REQ_FUA. For virtio-pmem this makes async_pmem_flush() allocate
> > and submit a child PREFLUSH bio chained to the parent.
> >
> > That child allocation is in the block submit path. Making it
> > blocking with GFP_NOIO can consume the same global bio mempool that
> > submit_bio() uses, while making it GFP_ATOMIC can fail under
> > pressure. A forced failure of the child allocation produced:
> >
> > virtio_pmem: forcing child bio allocation failure for test
> > Buffer I/O error on dev pmem0, logical block 0, lost sync page write
> > EXT4-fs (pmem0): I/O error while writing superblock
> > EXT4-fs (pmem0): mount failed
> >
> > Avoid the child bio completely. Flush FUA synchronously, like
> > REQ_PREFLUSH, then complete the parent after the flush. Since no
> > child bio can be created, async_pmem_flush() now only issues the
> > virtio flush and preserves negative errno values.
>
> Child flush is asynchronous (performs async flush to host side and returns).
> Till child bio completes guest userspace waits in pending IO state.
> It seems the current change will affect the behavior?
>
> Prior RFC [1] attempted to coalesce the async FLUSH request between guest &host.
> If there is interest, that approach could be revisited or integrated here?
>
> [1] https://lore.kernel.org/all/20220111161937.56272-1-pankaj.gupta.linux@gmail.com/#t
Yes, agreed. This does change the FUA path.
I will rework it to avoid the child bio allocation while keeping the
parent bio completion asynchronous, using your RFC as reference.
Regards,
Li
^ permalink raw reply
* [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling
From: Arseniy Krasnov @ 2026-06-28 18:20 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Michael S. Tsirkin,
Jason Wang, Bobby Eshleman, Xuan Zhuo, Eugenio Pérez,
Simon Horman
Cc: kvm, virtualization, netdev, linux-kernel, oxffffaa, rulkc,
Arseniy Krasnov
Logically it was based on TCP implementation, so to make further support
easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
this way, patch also adds handling case when 'msg_ubuf' is already set.
Signed-off-by: Arseniy Krasnov <avkrasnov@rulkc.org>
---
Changelog v1->v2:
* Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
already added.
Changelog v2->v3:
* Update commit message.
* Remove one empty line.
Changelog v3->v4:
* Update commit message.
net/vmw_vsock/virtio_transport_common.c | 47 ++++++++++++-------------
1 file changed, 22 insertions(+), 25 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 09475007165b..41c2a0b82a8e 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -328,38 +328,35 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
if (pkt_len == 0 && info->op == VIRTIO_VSOCK_OP_RW)
return pkt_len;
- if (info->msg) {
- /* If zerocopy is not enabled by 'setsockopt()', we behave as
- * there is no MSG_ZEROCOPY flag set.
+ if (info->msg && (info->msg->msg_flags & MSG_ZEROCOPY)) {
+ /* If 'info->msg' is not NULL, this is only VIRTIO_VSOCK_OP_RW.
+ * 'MSG_ZEROCOPY' flag handling here is based on the same flag
+ * handling from 'tcp_sendmsg_locked()'.
*/
- if (!sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY))
- info->msg->msg_flags &= ~MSG_ZEROCOPY;
+ if (info->msg->msg_ubuf) {
+ uarg = info->msg->msg_ubuf;
+ can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
+ } else if (sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY)) {
+ uarg = msg_zerocopy_realloc(sk_vsock(vsk), pkt_len,
+ NULL, false);
+ if (!uarg) {
+ virtio_transport_put_credit(vvs, pkt_len);
+ return -ENOMEM;
+ }
- if (info->msg->msg_flags & MSG_ZEROCOPY)
can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
+ if (!can_zcopy)
+ uarg_to_msgzc(uarg)->zerocopy = 0;
+ have_uref = true;
+ }
+
+ /* 'can_zcopy' means that this transmission will be
+ * in zerocopy way (e.g. using 'frags' array).
+ */
if (can_zcopy)
max_skb_len = min_t(u32, VIRTIO_VSOCK_MAX_PKT_BUF_SIZE,
(MAX_SKB_FRAGS * PAGE_SIZE));
-
- if (info->msg->msg_flags & MSG_ZEROCOPY &&
- info->op == VIRTIO_VSOCK_OP_RW) {
- uarg = info->msg->msg_ubuf;
-
- if (!uarg) {
- uarg = msg_zerocopy_realloc(sk_vsock(vsk),
- pkt_len, NULL, false);
- if (!uarg) {
- virtio_transport_put_credit(vvs, pkt_len);
- return -ENOMEM;
- }
-
- if (!can_zcopy)
- uarg_to_msgzc(uarg)->zerocopy = 0;
-
- have_uref = true;
- }
- }
}
rest_len = pkt_len;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling
From: Michael S. Tsirkin @ 2026-06-28 18:35 UTC (permalink / raw)
To: Arseniy Krasnov
Cc: Stefan Hajnoczi, Stefano Garzarella, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jason Wang,
Bobby Eshleman, Xuan Zhuo, Eugenio Pérez, Simon Horman, kvm,
virtualization, netdev, linux-kernel, oxffffaa, rulkc
In-Reply-To: <20260628182052.951760-1-avkrasnov@rulkc.org>
On Sun, Jun 28, 2026 at 09:20:52PM +0300, Arseniy Krasnov wrote:
> Logically it was based on TCP implementation, so to make further support
> easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
> this way, patch also adds handling case when 'msg_ubuf' is already set.
>
> Signed-off-by: Arseniy Krasnov <avkrasnov@rulkc.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> Changelog v1->v2:
> * Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
> already added.
> Changelog v2->v3:
> * Update commit message.
> * Remove one empty line.
> Changelog v3->v4:
> * Update commit message.
>
> net/vmw_vsock/virtio_transport_common.c | 47 ++++++++++++-------------
> 1 file changed, 22 insertions(+), 25 deletions(-)
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 09475007165b..41c2a0b82a8e 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -328,38 +328,35 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> if (pkt_len == 0 && info->op == VIRTIO_VSOCK_OP_RW)
> return pkt_len;
>
> - if (info->msg) {
> - /* If zerocopy is not enabled by 'setsockopt()', we behave as
> - * there is no MSG_ZEROCOPY flag set.
> + if (info->msg && (info->msg->msg_flags & MSG_ZEROCOPY)) {
> + /* If 'info->msg' is not NULL, this is only VIRTIO_VSOCK_OP_RW.
> + * 'MSG_ZEROCOPY' flag handling here is based on the same flag
> + * handling from 'tcp_sendmsg_locked()'.
> */
> - if (!sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY))
> - info->msg->msg_flags &= ~MSG_ZEROCOPY;
> + if (info->msg->msg_ubuf) {
> + uarg = info->msg->msg_ubuf;
> + can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
> + } else if (sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY)) {
> + uarg = msg_zerocopy_realloc(sk_vsock(vsk), pkt_len,
> + NULL, false);
> + if (!uarg) {
> + virtio_transport_put_credit(vvs, pkt_len);
> + return -ENOMEM;
> + }
>
> - if (info->msg->msg_flags & MSG_ZEROCOPY)
> can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
> + if (!can_zcopy)
> + uarg_to_msgzc(uarg)->zerocopy = 0;
>
> + have_uref = true;
> + }
> +
> + /* 'can_zcopy' means that this transmission will be
> + * in zerocopy way (e.g. using 'frags' array).
> + */
> if (can_zcopy)
> max_skb_len = min_t(u32, VIRTIO_VSOCK_MAX_PKT_BUF_SIZE,
> (MAX_SKB_FRAGS * PAGE_SIZE));
> -
> - if (info->msg->msg_flags & MSG_ZEROCOPY &&
> - info->op == VIRTIO_VSOCK_OP_RW) {
> - uarg = info->msg->msg_ubuf;
> -
> - if (!uarg) {
> - uarg = msg_zerocopy_realloc(sk_vsock(vsk),
> - pkt_len, NULL, false);
> - if (!uarg) {
> - virtio_transport_put_credit(vvs, pkt_len);
> - return -ENOMEM;
> - }
> -
> - if (!can_zcopy)
> - uarg_to_msgzc(uarg)->zerocopy = 0;
> -
> - have_uref = true;
> - }
> - }
> }
>
> rest_len = pkt_len;
> --
> 2.25.1
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update Jason Wang's email address
From: Jason Wang @ 2026-06-29 1:39 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: mst, virtualization, netdev, eperezma, kvm, linux-kernel
In-Reply-To: <20260626180433.3e302324@kernel.org>
On Sat, Jun 27, 2026 at 9:04 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> 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?
Exactly.
> Otherwise I think you'll get CCed twice (once for MAINTAINERS and once
> because you given tags to previous changes)
>
Yes, V2 will be sent soon.
Thanks
^ permalink raw reply
* [PATCH V2] MAINTAINERS: Update Jason Wang's email address
From: Jason Wang @ 2026-06-29 1:45 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>
---
Changes since V1:
- Add mailmap entry
---
.mailmap | 1 +
MAINTAINERS | 12 ++++++------
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/.mailmap b/.mailmap
index 23eb9a4b04f4..e7e639aeb23c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -373,6 +373,7 @@ Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@opinsys.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
+Jason Wang <jasowangio@gmail.com> <jasowang@redhat.com>
Jason Xing <kerneljasonxing@gmail.com> <kernelxing@tencent.com>
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
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 v2 1/2] tools/virtio: Add missing compat definitions for vhost_net_test
From: Yichong Chen @ 2026-06-29 2:21 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma
Cc: akpm, rppt, ljs, pabeni, chenyichong, linux-kernel,
virtualization
In-Reply-To: <20260629022124.131894-1-chenyichong@uniontech.com>
vhost_net_test builds virtio_ring.c in userspace.
Recent virtio headers pull in helper headers that are not provided by
the tools/virtio compatibility layer, including asm/percpu_types.h,
linux/completion.h, linux/mod_devicetable.h and
linux/virtio_features.h.
Add the missing compat definitions and the DMA attribute used by the
current virtio ring code.
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
---
tools/virtio/asm/percpu_types.h | 7 +++
tools/virtio/linux/completion.h | 9 ++++
tools/virtio/linux/device.h | 1 +
tools/virtio/linux/dma-mapping.h | 1 +
tools/virtio/linux/mod_devicetable.h | 14 +++++
tools/virtio/linux/virtio_features.h | 79 ++++++++++++++++++++++++++++
6 files changed, 111 insertions(+)
create mode 100644 tools/virtio/asm/percpu_types.h
create mode 100644 tools/virtio/linux/completion.h
create mode 100644 tools/virtio/linux/mod_devicetable.h
create mode 100644 tools/virtio/linux/virtio_features.h
diff --git a/tools/virtio/asm/percpu_types.h b/tools/virtio/asm/percpu_types.h
new file mode 100644
index 000000000000..4eb53d93c099
--- /dev/null
+++ b/tools/virtio/asm/percpu_types.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_PERCPU_TYPES_H
+#define _ASM_PERCPU_TYPES_H
+
+#define __percpu_qual
+
+#endif /* _ASM_PERCPU_TYPES_H */
diff --git a/tools/virtio/linux/completion.h b/tools/virtio/linux/completion.h
new file mode 100644
index 000000000000..5e54b679721b
--- /dev/null
+++ b/tools/virtio/linux/completion.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_COMPLETION_H
+#define _LINUX_COMPLETION_H
+
+struct completion {
+ unsigned int done;
+};
+
+#endif /* _LINUX_COMPLETION_H */
diff --git a/tools/virtio/linux/device.h b/tools/virtio/linux/device.h
index 075c2140d975..abf100cb0023 100644
--- a/tools/virtio/linux/device.h
+++ b/tools/virtio/linux/device.h
@@ -1,4 +1,5 @@
#ifndef LINUX_DEVICE_H
+#define LINUX_DEVICE_H
struct device {
void *parent;
diff --git a/tools/virtio/linux/dma-mapping.h b/tools/virtio/linux/dma-mapping.h
index 8d1a16cb20db..b9fc5e8338e3 100644
--- a/tools/virtio/linux/dma-mapping.h
+++ b/tools/virtio/linux/dma-mapping.h
@@ -61,5 +61,6 @@ enum dma_data_direction {
#define DMA_MAPPING_ERROR (~(dma_addr_t)0)
#define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11)
+#define DMA_ATTR_DEBUGGING_IGNORE_CACHELINES 0
#endif
diff --git a/tools/virtio/linux/mod_devicetable.h b/tools/virtio/linux/mod_devicetable.h
new file mode 100644
index 000000000000..3ba594b8229d
--- /dev/null
+++ b/tools/virtio/linux/mod_devicetable.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MOD_DEVICETABLE_H
+#define _LINUX_MOD_DEVICETABLE_H
+
+#include <linux/types.h>
+
+struct virtio_device_id {
+ __u32 device;
+ __u32 vendor;
+};
+
+#define VIRTIO_DEV_ANY_ID 0xffffffff
+
+#endif /* _LINUX_MOD_DEVICETABLE_H */
diff --git a/tools/virtio/linux/virtio_features.h b/tools/virtio/linux/virtio_features.h
new file mode 100644
index 000000000000..04cbb9622ec7
--- /dev/null
+++ b/tools/virtio/linux/virtio_features.h
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_VIRTIO_FEATURES_H
+#define _LINUX_VIRTIO_FEATURES_H
+
+#include <linux/bug.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+#define VIRTIO_FEATURES_U64S 2
+#define VIRTIO_FEATURES_BITS (VIRTIO_FEATURES_U64S * 64)
+
+#define VIRTIO_BIT(b) (1ULL << ((b) & 0x3f))
+#define VIRTIO_U64(b) ((b) >> 6)
+
+#define VIRTIO_DECLARE_FEATURES(name) \
+ union { \
+ u64 name; \
+ u64 name##_array[VIRTIO_FEATURES_U64S];\
+ }
+
+static inline bool virtio_features_chk_bit(unsigned int bit)
+{
+ return bit < VIRTIO_FEATURES_BITS;
+}
+
+static inline bool virtio_features_test_bit(const u64 *features,
+ unsigned int bit)
+{
+ return virtio_features_chk_bit(bit) &&
+ !!(features[VIRTIO_U64(bit)] & VIRTIO_BIT(bit));
+}
+
+static inline void virtio_features_set_bit(u64 *features, unsigned int bit)
+{
+ if (virtio_features_chk_bit(bit))
+ features[VIRTIO_U64(bit)] |= VIRTIO_BIT(bit);
+}
+
+static inline void virtio_features_clear_bit(u64 *features, unsigned int bit)
+{
+ if (virtio_features_chk_bit(bit))
+ features[VIRTIO_U64(bit)] &= ~VIRTIO_BIT(bit);
+}
+
+static inline void virtio_features_zero(u64 *features)
+{
+ memset(features, 0, sizeof(features[0]) * VIRTIO_FEATURES_U64S);
+}
+
+static inline void virtio_features_from_u64(u64 *features, u64 from)
+{
+ virtio_features_zero(features);
+ features[0] = from;
+}
+
+static inline bool virtio_features_equal(const u64 *f1, const u64 *f2)
+{
+ int i;
+
+ for (i = 0; i < VIRTIO_FEATURES_U64S; ++i)
+ if (f1[i] != f2[i])
+ return false;
+ return true;
+}
+
+static inline void virtio_features_copy(u64 *to, const u64 *from)
+{
+ memcpy(to, from, sizeof(to[0]) * VIRTIO_FEATURES_U64S);
+}
+
+static inline void virtio_features_andnot(u64 *to, const u64 *f1, const u64 *f2)
+{
+ int i;
+
+ for (i = 0; i < VIRTIO_FEATURES_U64S; i++)
+ to[i] = f1[i] & ~f2[i];
+}
+
+#endif /* _LINUX_VIRTIO_FEATURES_H */
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/2] tools: Fix tools/virtio test build
From: Yichong Chen @ 2026-06-29 2:21 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma
Cc: akpm, rppt, ljs, pabeni, chenyichong, linux-kernel,
virtualization
Hi,
This series fixes build failures hit by:
make -C tools/virtio test
It is based on linux-next commit:
commit 3d5670d672ae ("Add linux-next specific files for 20260626")
Patch 1 adds tools/virtio compatibility definitions needed by current
virtio headers when building the tools/virtio tests. Patch 2 makes
tools/include/linux/overflow.h include stdint.h for SIZE_MAX, which is
used by its size helper functions.
With the series applied, make -C tools/virtio test builds virtio_test,
vringh_test and vhost_net_test successfully.
Tested on x86_64 and arm64 with:
make -C tools/virtio clean
make -C tools/virtio test
Changes in v2:
- Rebase and retest on linux-next.
- Add the missing asm/percpu_types.h compat header reported by Eugenio.
- Keep the tools/virtio compat definitions aligned with current
virtio_features.h helpers.
- Drop the slab.h kmalloc_obj/kmalloc_objs change because linux-next
already defines them in tools/virtio/linux/kernel.h.
Yichong Chen (2):
tools/virtio: Add missing compat definitions for vhost_net_test
tools/include: Include stdint.h for SIZE_MAX in overflow.h
tools/include/linux/overflow.h | 1 +
tools/virtio/asm/percpu_types.h | 7 +++
tools/virtio/linux/completion.h | 9 ++++
tools/virtio/linux/device.h | 1 +
tools/virtio/linux/dma-mapping.h | 1 +
tools/virtio/linux/mod_devicetable.h | 14 +++++
tools/virtio/linux/virtio_features.h | 79 ++++++++++++++++++++++++++++
7 files changed, 112 insertions(+)
create mode 100644 tools/virtio/asm/percpu_types.h
create mode 100644 tools/virtio/linux/completion.h
create mode 100644 tools/virtio/linux/mod_devicetable.h
create mode 100644 tools/virtio/linux/virtio_features.h
--
2.51.0
^ permalink raw reply
* [PATCH v2 2/2] tools/include: Include stdint.h for SIZE_MAX in overflow.h
From: Yichong Chen @ 2026-06-29 2:21 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma
Cc: akpm, rppt, ljs, pabeni, chenyichong, linux-kernel,
virtualization
In-Reply-To: <20260629022124.131894-1-chenyichong@uniontech.com>
tools/include/linux/overflow.h uses SIZE_MAX in its size helper
functions.
Include stdint.h so tools users that include overflow.h without another
SIZE_MAX provider can build.
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
---
tools/include/linux/overflow.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/include/linux/overflow.h b/tools/include/linux/overflow.h
index 3427d7880326..98963688143f 100644
--- a/tools/include/linux/overflow.h
+++ b/tools/include/linux/overflow.h
@@ -1,4 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+#include <stdint.h>
#ifndef __LINUX_OVERFLOW_H
#define __LINUX_OVERFLOW_H
--
2.51.0
^ permalink raw reply related
* [PATCH v5] virtio_net: disable cb when NAPI is busy-polled
From: Longjun Tang @ 2026-06-29 2:42 UTC (permalink / raw)
To: kuba, horms
Cc: mst, jasowang, edumazet, virtualization, netdev, tanglongjun,
lange_tang
From: Longjun Tang <tanglongjun@kylinos.cn>
When busy-poll is active, napi_schedule_prep() returns false in
virtqueue_napi_schedule(), so virtqueue_disable_cb() is skipped.
The device may keep firing irqs until reaches virtqueue_napi_complete().
Under load (received == budget), it will lead to a large number
of spurious interrupts.
Fix it by disabling the callback at the virtnet_poll() entry.
This keeps the callback off while we poll and it is re-enabled by
virtqueue_napi_complete() when going idle.
Fixes: ceef438d613f ("virtio_net: remove custom busy_poll")
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Longjun Tang <tanglongjun@kylinos.cn>
---
V4 -> V5: Guard disable_cb with budget to avoid netpoll stall
V3 -> V4: Update commit message and remove some comments
V2 -> V3: Add fixes tag
V1 -> V2: Remain agnostic to busy polling
---
drivers/net/virtio_net.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7d2eeb9b1226..0b3f1bb227d2 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3008,6 +3008,9 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
unsigned int xdp_xmit = 0;
bool napi_complete;
+ if (budget)
+ virtqueue_disable_cb(rq->vq);
+
virtnet_poll_cleantx(rq, budget);
received = virtnet_receive(rq, budget, &xdp_xmit);
--
2.43.0
^ permalink raw reply related
* [PATCH] virtio_dma_buf: fix typo in kdoc comment: get_uid -> get_uuid
From: lirongqing @ 2026-06-29 3:31 UTC (permalink / raw)
To: Michael S . Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Gerd Hoffmann, David Stevens, virtualization, linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
The @get_uid tag in the virtio_dma_buf_ops kdoc comment is a typo;
the actual field name is get_uuid.
Fixes: a0308938ec81 ("virtio: add dma-buf support for exported objects")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
include/linux/virtio_dma_buf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/virtio_dma_buf.h b/include/linux/virtio_dma_buf.h
index a2fdf21..545ac5f 100644
--- a/include/linux/virtio_dma_buf.h
+++ b/include/linux/virtio_dma_buf.h
@@ -17,7 +17,7 @@
* @ops: the base dma_buf_ops. ops.attach MUST be virtio_dma_buf_attach.
* @device_attach: [optional] callback invoked by virtio_dma_buf_attach during
* all attach operations.
- * @get_uid: [required] callback to get the uuid of the exported object.
+ * @get_uuid: [required] callback to get the uuid of the exported object.
*/
struct virtio_dma_buf_ops {
struct dma_buf_ops ops;
--
2.9.4
^ permalink raw reply related
* [PATCH] virtio_mem: fix hardcoded 'vm' variable in bbm iteration macros
From: lirongqing @ 2026-06-29 3:37 UTC (permalink / raw)
To: David Hildenbrand, Michael S . Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
virtio_mem_bbm_for_each_bb() and virtio_mem_bbm_for_each_bb_rev()
accept a '_vm' parameter to allow callers to pass any variable name
referring to the virtio_mem instance. However, the 'for' loop
initializer and part of the loop condition use the bare name 'vm'
instead of the macro parameter '_vm':
All current call sites happen to pass a variable named 'vm', so the
bug is latent and does not cause a regression today. Nevertheless,
the macros are formally broken: any future caller using a different
variable name would silently capture the outer 'vm' from the
enclosing scope, leading to incorrect iteration bounds.
Fix by replacing all bare 'vm->' references inside the macros with
the '_vm' parameter, and wrap in parentheses following kernel macro
hygiene conventions.
Fixes: 4ba50cd3355d ("virtio-mem: Big Block Mode (BBM) memory hotplug")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
drivers/virtio/virtio_mem.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 11c4415..82a285c 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -423,14 +423,14 @@ static int virtio_mem_bbm_bb_states_prepare_next_bb(struct virtio_mem *vm)
}
#define virtio_mem_bbm_for_each_bb(_vm, _bb_id, _state) \
- for (_bb_id = vm->bbm.first_bb_id; \
- _bb_id < vm->bbm.next_bb_id && _vm->bbm.bb_count[_state]; \
+ for (_bb_id = (_vm)->bbm.first_bb_id; \
+ _bb_id < (_vm)->bbm.next_bb_id && (_vm)->bbm.bb_count[_state]; \
_bb_id++) \
if (virtio_mem_bbm_get_bb_state(_vm, _bb_id) == _state)
#define virtio_mem_bbm_for_each_bb_rev(_vm, _bb_id, _state) \
- for (_bb_id = vm->bbm.next_bb_id - 1; \
- _bb_id >= vm->bbm.first_bb_id && _vm->bbm.bb_count[_state]; \
+ for (_bb_id = (_vm)->bbm.next_bb_id - 1; \
+ _bb_id >= (_vm)->bbm.first_bb_id && (_vm)->bbm.bb_count[_state]; \
_bb_id--) \
if (virtio_mem_bbm_get_bb_state(_vm, _bb_id) == _state)
--
2.9.4
^ permalink raw reply related
* [PATCH] virtio_pci: fix wrong queue index for admin vq in intx path
From: lirongqing @ 2026-06-29 3:35 UTC (permalink / raw)
To: Michael S . Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Jiri Pirko, virtualization, linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
In vp_find_vqs_intx(), the admin vq was set up using the local
queue_idx counter instead of avq->vq_index (the actual queue index
obtained from the device). This differs from vp_find_vqs_msix() which
correctly uses avq->vq_index. Using the wrong index causes the admin
virtqueue to be mapped to an incorrect hardware queue.
Fix it by using avq->vq_index consistent with the msix path.
Fixes: af22bbe1f4a5 ("virtio: create admin queues alongside other virtqueues")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
drivers/virtio/virtio_pci_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index 164f480..10371ec 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -499,7 +499,7 @@ static int vp_find_vqs_intx(struct virtio_device *vdev, unsigned int nvqs,
if (!avq_num)
return 0;
sprintf(avq->name, "avq.%u", avq->vq_index);
- vq = vp_setup_vq(vdev, queue_idx++, vp_modern_avq_done, avq->name,
+ vq = vp_setup_vq(vdev, avq->vq_index, vp_modern_avq_done, avq->name,
false, VIRTIO_MSI_NO_VECTOR,
&vp_dev->admin_vq.info);
if (IS_ERR(vq)) {
--
2.9.4
^ permalink raw reply related
* Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()
From: Thomas Weißschuh @ 2026-06-29 3:55 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: <87fr29ib4v.ffs@fw13>
On Fri, Jun 26, 2026 at 05:17:52PM +0200, Thomas Gleixner wrote:
> 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?
Looks good, thanks.
The corresponding structure definitions are a also affected, though.
> 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
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