* [PATCH v4 2/5] vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause
From: Andrey Drobyshev @ 2026-07-14 15:16 UTC (permalink / raw)
To: linux-kernel
Cc: kvm, virtualization, netdev, sgarzare, mst, stefanha,
dongli.zhang, maciej.szmigiero, bchaney, mark.kanda, ptikhomirov,
den, andrey.drobyshev
In-Reply-To: <20260714151638.143019-1-andrey.drobyshev@virtuozzo.com>
Earlier commit bb26ed5f3a8b ("vhost/vsock: Refuse the connection
immediately when guest isn't ready") added a fast-fail in
vhost_transport_send_pkt(). It rejects every host send with -EHOSTUNREACH
until the destination calls SET_RUNNING(1). The fast-fail condition checks
whether device's backends are dropped, and if they're, the guest is
considered to be not ready.
However, there might be other reasons for backends to be nulled. In
particular, when QEMU is performing CPR (checkpoint-restore) migration,
device ownership is being RESET and SET again, which leads to backends
drop and reattach. If we end up connecting during this window, an
AF_VSOCK client gets -EHOSTUNREACH, which is wrong.
Add an 'ever_started' flag which is set once in vhost_vsock_start() and is
never cleared. The behaviour changes to:
* When device was never started -> flag is unset -> no listener can
exist yet -> fast-fail;
* Once the device starts -> flag is set -> we don't fast-fail ->
we queue and preserve during any later stop / CPR pause.
The VHOST_RESET_OWNER ioctl is implemented in a following patch, and
without RESET_OWNER the problem we fix here isn't manifesting - thus
this patch is a preparation to support RESET_OWNER.
Important caveat: after the first start, a connect during any stopped
window is queued instead of fast-failed. That was the behaviour before
the patch bb26ed5f3a8b, and we're restoring it now. However we still
keep the behaviour originally intended by that commit (i.e. fast-fail if
there's no real listener yet) while fixing the CPR path.
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
---
drivers/vhost/vsock.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index b12221ce6faf..27169a09e87e 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -61,6 +61,7 @@ struct vhost_vsock {
u32 guest_cid;
bool seqpacket_allow;
+ bool ever_started; /* set on first SET_RUNNING(1); never cleared */
};
static u32 vhost_transport_get_local_cid(void)
@@ -302,17 +303,12 @@ vhost_transport_send_pkt(struct sk_buff *skb, struct net *net)
return -ENODEV;
}
- /* Fast-fail if the guest hasn't enabled the RX vq yet. Queuing the packet
- * and making the caller wait is pointless: even if the guest manages to init
- * within the timeout, it'll immediately reply with RST, because there's no
- * listener on the port yet.
- *
- * vhost_vq_get_backend() without vq->mutex is acceptable here: locking
- * the mutex would be too expensive in this hot path, and we already have
- * all the outcomes covered: if the backend becomes NULL right after the check,
- * vhost_transport_do_send_pkt() will check it under the mutex anyway.
+ /* Fast-fail until the guest first enables the device (SET_RUNNING(1)).
+ * Before that there is no listener, so queuing is pointless.
+ * 'ever_started' is never cleared, so once we're up we keep queuing
+ * across later stop / CPR-pause windows.
*/
- if (unlikely(!data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX])))) {
+ if (unlikely(!READ_ONCE(vsock->ever_started))) {
rcu_read_unlock();
kfree_skb(skb);
return -EHOSTUNREACH;
@@ -640,6 +636,11 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)
mutex_unlock(&vq->mutex);
}
+ /* Set 'ever_started' flag on the first start; never cleared, so send_pkt
+ * keeps queuing (instead of fast-failing) on later stop / CPR pauses.
+ */
+ WRITE_ONCE(vsock->ever_started, true);
+
/* Some packets may have been queued before the device was started,
* let's kick the send worker to send them.
*/
@@ -728,6 +729,7 @@ static int vhost_vsock_dev_open(struct inode *inode, struct file *file)
vsock->guest_cid = 0; /* no CID assigned yet */
vsock->seqpacket_allow = false;
+ vsock->ever_started = false;
atomic_set(&vsock->queued_replies, 0);
--
2.47.1
^ permalink raw reply related
* [PATCH v4 1/5] vhost/vsock: split out vhost_vsock_drop_backends helper
From: Andrey Drobyshev @ 2026-07-14 15:16 UTC (permalink / raw)
To: linux-kernel
Cc: kvm, virtualization, netdev, sgarzare, mst, stefanha,
dongli.zhang, maciej.szmigiero, bchaney, mark.kanda, ptikhomirov,
den, andrey.drobyshev
In-Reply-To: <20260714151638.143019-1-andrey.drobyshev@virtuozzo.com>
From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Split the actual backend dropping part from vhost_vsock_stop. We're
going to need it for the VHOST_RESET_OWNER implementation in the
following patch, when vsock->dev.mutex is already taken and owner is
checked.
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
---
drivers/vhost/vsock.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 9aaab6bb8061..b12221ce6faf 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -664,9 +664,24 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)
return ret;
}
-static int vhost_vsock_stop(struct vhost_vsock *vsock, bool check_owner)
+static void vhost_vsock_drop_backends(struct vhost_vsock *vsock)
{
+ struct vhost_virtqueue *vq;
size_t i;
+
+ lockdep_assert_held(&vsock->dev.mutex);
+
+ for (i = 0; i < ARRAY_SIZE(vsock->vqs); i++) {
+ vq = &vsock->vqs[i];
+
+ mutex_lock(&vq->mutex);
+ vhost_vq_set_backend(vq, NULL);
+ mutex_unlock(&vq->mutex);
+ }
+}
+
+static int vhost_vsock_stop(struct vhost_vsock *vsock, bool check_owner)
+{
int ret = 0;
mutex_lock(&vsock->dev.mutex);
@@ -677,14 +692,7 @@ static int vhost_vsock_stop(struct vhost_vsock *vsock, bool check_owner)
goto err;
}
- for (i = 0; i < ARRAY_SIZE(vsock->vqs); i++) {
- struct vhost_virtqueue *vq = &vsock->vqs[i];
-
- mutex_lock(&vq->mutex);
- vhost_vq_set_backend(vq, NULL);
- mutex_unlock(&vq->mutex);
- }
-
+ vhost_vsock_drop_backends(vsock);
err:
mutex_unlock(&vsock->dev.mutex);
return ret;
--
2.47.1
^ permalink raw reply related
* [PATCH v4 0/5] vhost/vsock: add support for VHOST_RESET_OWNER and CPR migration
From: Andrey Drobyshev @ 2026-07-14 15:16 UTC (permalink / raw)
To: linux-kernel
Cc: kvm, virtualization, netdev, sgarzare, mst, stefanha,
dongli.zhang, maciej.szmigiero, bchaney, mark.kanda, ptikhomirov,
den, andrey.drobyshev
The main change since v3: as suggested by Stefano, the worker teardown
race is now fixed where it actually lives, i.e. in vhost_workers_free(),
instead of being guarded from the vsock side. The new patch 4 makes the
teardown wait out the RCU readers which might still be queueing work on
a worker, and then run whatever they queued, before the workers are
freed.
With the teardown itself made safe, queueing work on a stopped device
is harmless again: the work handlers check the backend under vq->mutex
and simply return. So the backend guards in send_pkt()/cancel_pkt()
and the synchronize_rcu() in reset_owner() from v3 are no longer needed
and are gone.
v3 -> v4:
* Patch 2:
- rename 'started' -> 'ever_started';
- reword commit message;
* Patch 3: reword commit message and code comment;
* Patch 4 (NEW) ("vhost: synchronize with RCU readers when freeing workers"):
- fix the vq->worker UAF and the stuck VHOST_WORK_QUEUED bit
generically in vhost_workers_free();
* Patch 4 -> 5 ("vhost/vsock: add VHOST_RESET_OWNER ioctl"):
- drop the backend guards in send_pkt()/cancel_pkt() and the
synchronize_rcu() in reset_owner() - covered by patch 4 now;
- make vhost_vsock_reset_owner() return long;
- reword commit message.
v3: https://lore.kernel.org/virtualization/20260625155416.480669-1-andrey.drobyshev@virtuozzo.com
Andrey Drobyshev (3):
vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause
vhost/vsock: re-scan TX virtqueue on device start
vhost: synchronize with RCU readers when freeing workers
Pavel Tikhomirov (2):
vhost/vsock: split out vhost_vsock_drop_backends helper
vhost/vsock: add VHOST_RESET_OWNER ioctl
drivers/vhost/vhost.c | 15 ++++++++++
drivers/vhost/vsock.c | 80 +++++++++++++++++++++++++++++++++++++++------------
2 files changed, 76 insertions(+), 19 deletions(-)
--
2.47.1
^ permalink raw reply
* Re: [RFC] virtio_balloon: fix Use-After-Free in page reporting during PM freeze
From: Michael S. Tsirkin @ 2026-07-14 13:24 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Link Lin, Andrew Morton, Vlastimil Babka, virtualization,
linux-mm, linux-kernel, prasin, rientjes, duenwen, jasowang,
xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, stable
In-Reply-To: <8d316b6c-41fb-4ae3-8923-3b649b92b33d@kernel.org>
On Tue, Jul 14, 2026 at 03:17:42PM +0200, David Hildenbrand (Arm) wrote:
> On 7/10/26 00:43, Link Lin wrote:
> > During system power management freeze (e.g. ACPI S3 suspend or S4
> > hibernation), virtballoon_freeze() calls remove_common() to reset the
> > virtio device and delete all virtqueues via vdev->config->del_vqs().
> > However, unlike virtballoon_remove(), virtballoon_freeze() fails to call
> > page_reporting_unregister(&vb->pr_dev_info).
> >
> > The comment in virtballoon_freeze() states:
> > /*
> > * The workqueue is already frozen by the PM core before this
> > * function is called.
> > */
> >
> > While this comment was accurate in 2011 for balloon-internal workqueues
> > (such as balloon_wq, which was created with WQ_FREEZABLE and is paused
> > by the PM freezer), it is invalid for Free Page Reporting.
> >
> > Free Page Reporting (mm/page_reporting.c) schedules its delayed work
> > (prdev->work) on the global system_wq. Because system_wq lacks the
> > WQ_FREEZABLE flag, the PM freezer (freeze_workqueues_busy()) explicitly
> > skips it. Consequently, page_reporting_process() on system_wq remains
> > active and unfrozen throughout device suspend.
> >
> > If memory is freed into the buddy allocator or a delayed work timer
> > expires while the device is being frozen, page_reporting_process() fires
> > on system_wq and calls virtballoon_free_page_report(). This function
> > passes vb->reporting_vq into virtqueue_add_inbuf() / virtqueue_add_split().
> > Because the virtqueues were already destroyed by del_vqs(), this results
> > in a Use-After-Free / General Protection Fault:
> >
> > [ 250.709271] general protection fault, probably for non-canonical address 0x7f728084daf08d5e: 0000 [#1] SMP PTI
> > [ 250.732967] CPU: 2 PID: 38 Comm: kworker/2:1 Not tainted 5.10.0-44-cloud-amd64 #1 Debian 5.10.257-1
> > [ 250.751575] Workqueue: events page_reporting_process
> > [ 250.756665] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring]
> > ...
> > [ 250.867678] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon]
> > [ 250.883446] page_reporting_process+0x225/0x4f0
> >
> > (Note: The OOM Notifier and Shrinker/Free Page Hinting features suffer
> > from an identical lifecycle flaw and are also vulnerable to UAFs during
> > S4 hibernation when memory pressure spikes. This patch focuses on Free
> > Page Reporting, which runs periodically, to ensure clean backports to
> > stable kernels).
> >
> > Fix this by:
> > 1. Unregistering page reporting in virtballoon_freeze() prior to calling
> > remove_common(). This clears the RCU pr_dev_info pointer and flushes/
> > cancels prdev->work on system_wq via cancel_delayed_work_sync().
> > 2. Re-registering page reporting in virtballoon_restore() after the
> > virtqueues are re-initialized and virtio_device_ready() has been called.
> > 3. Unwinding virtqueue initialization via remove_common() in
> > virtballoon_restore() if page_reporting_register() fails.
> >
> > Fixes: 924a663f75e2 ("virtio-balloon: Reporting free page reservations")
> > Cc: stable@vger.kernel.org
> > Cc: jasowang@redhat.com
> > Cc: xuanzhuo@linux.alibaba.com
> > Cc: Ammar Faizi <ammarfaizi2@openresty.com>
> > Cc: jiaqiyan@google.com
> > Cc: ahwilkins@google.com
> > Cc: Greg Thelen <gthelen@google.com>
> > Cc: Alexander Duyck <alexander.duyck@gmail.com>
> > Signed-off-by: Link Lin <linkl@google.com>
> > ---
> > drivers/virtio/virtio_balloon.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > index a1b2c3d4e5f6..45a90fb3abf8 100640
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -1055,6 +1055,9 @@ static int virtballoon_freeze(struct virtio_device *vdev)
> > * The workqueue is already frozen by the PM core before this
> > * function is called.
> > */
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
> > + page_reporting_unregister(&vb->pr_dev_info);
> > +
> > remove_common(vb);
> > return 0;
> > }
> >
> > static int virtballoon_restore(struct virtio_device *vdev)
> > {
> > struct virtio_balloon *vb = vdev->priv;
> > int ret;
> >
> > ret = init_vqs(vdev->priv);
> > if (ret)
> > return ret;
> >
> > virtio_device_ready(vdev);
> >
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
> > + ret = page_reporting_register(&vb->pr_dev_info);
> > + if (ret)
> > + goto out_remove_vqs;
> > + }
>
> Hm, that failure handling is rather nasty.
>
>
> In virtballoon_freeze() we document:
>
> "The workqueue is already frozen by the PM core before this function is called"
>
> Your report states:
>
> "Workqueue: events page_reporting_process"
>
>
> I assume that workqueue is not frozen yet because ... it's not freezable :)
>
> So could we queue to system_freezable_wq instead, or define our own freezable
> workqueue there? Then a driver doesn't have to worry about that.
>
> --
> Cheers,
>
> David
+1. Just system_freezable_wq will do the trick.
--
MST
^ permalink raw reply
* Re: [PATCH] virtio_net: fix infinite loop in virtnet_poll_cleantx when device is broken
From: Michael S. Tsirkin @ 2026-07-14 13:17 UTC (permalink / raw)
To: Jinqian Yang
Cc: jasowang, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, virtualization, linux-kernel, liuyonglong,
wangzhou1, linuxarm
In-Reply-To: <20260713132025.703147-1-yangjinqian1@huawei.com>
On Mon, Jul 13, 2026 at 09:20:25PM +0800, Jinqian Yang wrote:
> virtnet_poll_cleantx() contains a do-while loop that cleans up
> transmitted TX buffers and calls virtqueue_enable_cb_delayed() to check
> whether more buffers need processing. When the virtio backend stops
> responding during guest reboot, used->idx is never updated, so
> virtqueue_enable_cb_delayed() always returns false and the loop never
> terminates. Then it will block reboot process, and the guest will hang.
>
> The problem occurs during guest reboot under network traffic:
>
> 1. kernel_restart() -> device_shutdown() traverses the device list
> 2. virtio_dev_shutdown() calls virtio_break_device() which sets
> vq->broken = true
> 3. virtio_dev_shutdown() then calls virtio_synchronize_cbs() to wait
> for in-flight callbacks to complete
> 4. A virtio interrupt fires, softirq is deferred to ksoftirqd which
> calls net_rx_action() -> virtnet_poll() -> virtnet_poll_cleantx()
> 5. virtnet_poll_cleantx() enters the do-while loop and never exits
> because the QEMU backend has stopped updating used->idx, despite
> vq->broken having been set to true in step 2.
>
> Since the loop runs inside ksoftirqd (a SCHED_OTHER kthread), it is
> visible to the scheduler and does not trigger a hard lockup. However,
> the kthread never leaves the loop, so RCU detects it as a CPU stall
> and reports it periodically. Meanwhile, the reboot process remains
> blocked in device_shutdown() because virtio_dev_shutdown() cannot
> complete its synchronization step, and the guest hangs permanently.
>
> This can be reproduced on a guest with a virtio-net device: run iperf3
> traffic in the guest, then trigger reboot. The reboot occasionally hangs
> permanently with RCU stall on ksoftirqd.
>
> Observed on ARM64 KVM guest:
>
> CPU#1 RCU stall (ksoftirqd/1), repeated periodically:
> virtqueue_enable_cb_delayed_split <- virtnet_poll <- __napi_poll <-
> net_rx_action <- handle_softirqs <- run_ksoftirqd <-
> smpboot_thread_fn <- kthread
>
> Fix by adding a virtqueue_is_broken() check to the loop condition, so
> that the loop exits immediately when the device is broken, allowing
> the device shutdown to proceed.
>
> Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com>
I'd expect lots of drivers have this issue? Wouldn't it make more sense
to check virtqueue_is_broken in
virtqueue_enable_cb_delayed/virtqueue_enable_cb? This way it works for
all drivers.
> ---
> drivers/net/virtio_net.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7d2eeb9b1226..c8d2d420c31d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2970,7 +2970,8 @@ static void virtnet_poll_cleantx(struct receive_queue *rq, int budget)
> do {
> virtqueue_disable_cb(sq->vq);
> free_old_xmit(sq, txq, !!budget);
> - } while (unlikely(!virtqueue_enable_cb_delayed(sq->vq)));
> + } while (!virtqueue_is_broken(sq->vq) &&
> + unlikely(!virtqueue_enable_cb_delayed(sq->vq)));
>
> if (sq->vq->num_free >= MAX_SKB_FRAGS + 2)
> virtnet_tx_wake_queue(vi, sq);
> --
> 2.33.0
^ permalink raw reply
* Re: [RFC] virtio_balloon: fix Use-After-Free in page reporting during PM freeze
From: David Hildenbrand (Arm) @ 2026-07-14 13:17 UTC (permalink / raw)
To: Link Lin, Andrew Morton, Vlastimil Babka, Michael S . Tsirkin
Cc: virtualization, linux-mm, linux-kernel, prasin, rientjes, duenwen,
jasowang, xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, stable
In-Reply-To: <20260709224330.946683-1-linkl@google.com>
On 7/10/26 00:43, Link Lin wrote:
> During system power management freeze (e.g. ACPI S3 suspend or S4
> hibernation), virtballoon_freeze() calls remove_common() to reset the
> virtio device and delete all virtqueues via vdev->config->del_vqs().
> However, unlike virtballoon_remove(), virtballoon_freeze() fails to call
> page_reporting_unregister(&vb->pr_dev_info).
>
> The comment in virtballoon_freeze() states:
> /*
> * The workqueue is already frozen by the PM core before this
> * function is called.
> */
>
> While this comment was accurate in 2011 for balloon-internal workqueues
> (such as balloon_wq, which was created with WQ_FREEZABLE and is paused
> by the PM freezer), it is invalid for Free Page Reporting.
>
> Free Page Reporting (mm/page_reporting.c) schedules its delayed work
> (prdev->work) on the global system_wq. Because system_wq lacks the
> WQ_FREEZABLE flag, the PM freezer (freeze_workqueues_busy()) explicitly
> skips it. Consequently, page_reporting_process() on system_wq remains
> active and unfrozen throughout device suspend.
>
> If memory is freed into the buddy allocator or a delayed work timer
> expires while the device is being frozen, page_reporting_process() fires
> on system_wq and calls virtballoon_free_page_report(). This function
> passes vb->reporting_vq into virtqueue_add_inbuf() / virtqueue_add_split().
> Because the virtqueues were already destroyed by del_vqs(), this results
> in a Use-After-Free / General Protection Fault:
>
> [ 250.709271] general protection fault, probably for non-canonical address 0x7f728084daf08d5e: 0000 [#1] SMP PTI
> [ 250.732967] CPU: 2 PID: 38 Comm: kworker/2:1 Not tainted 5.10.0-44-cloud-amd64 #1 Debian 5.10.257-1
> [ 250.751575] Workqueue: events page_reporting_process
> [ 250.756665] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring]
> ...
> [ 250.867678] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon]
> [ 250.883446] page_reporting_process+0x225/0x4f0
>
> (Note: The OOM Notifier and Shrinker/Free Page Hinting features suffer
> from an identical lifecycle flaw and are also vulnerable to UAFs during
> S4 hibernation when memory pressure spikes. This patch focuses on Free
> Page Reporting, which runs periodically, to ensure clean backports to
> stable kernels).
>
> Fix this by:
> 1. Unregistering page reporting in virtballoon_freeze() prior to calling
> remove_common(). This clears the RCU pr_dev_info pointer and flushes/
> cancels prdev->work on system_wq via cancel_delayed_work_sync().
> 2. Re-registering page reporting in virtballoon_restore() after the
> virtqueues are re-initialized and virtio_device_ready() has been called.
> 3. Unwinding virtqueue initialization via remove_common() in
> virtballoon_restore() if page_reporting_register() fails.
>
> Fixes: 924a663f75e2 ("virtio-balloon: Reporting free page reservations")
> Cc: stable@vger.kernel.org
> Cc: jasowang@redhat.com
> Cc: xuanzhuo@linux.alibaba.com
> Cc: Ammar Faizi <ammarfaizi2@openresty.com>
> Cc: jiaqiyan@google.com
> Cc: ahwilkins@google.com
> Cc: Greg Thelen <gthelen@google.com>
> Cc: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Link Lin <linkl@google.com>
> ---
> drivers/virtio/virtio_balloon.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index a1b2c3d4e5f6..45a90fb3abf8 100640
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -1055,6 +1055,9 @@ static int virtballoon_freeze(struct virtio_device *vdev)
> * The workqueue is already frozen by the PM core before this
> * function is called.
> */
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
> + page_reporting_unregister(&vb->pr_dev_info);
> +
> remove_common(vb);
> return 0;
> }
>
> static int virtballoon_restore(struct virtio_device *vdev)
> {
> struct virtio_balloon *vb = vdev->priv;
> int ret;
>
> ret = init_vqs(vdev->priv);
> if (ret)
> return ret;
>
> virtio_device_ready(vdev);
>
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
> + ret = page_reporting_register(&vb->pr_dev_info);
> + if (ret)
> + goto out_remove_vqs;
> + }
Hm, that failure handling is rather nasty.
In virtballoon_freeze() we document:
"The workqueue is already frozen by the PM core before this function is called"
Your report states:
"Workqueue: events page_reporting_process"
I assume that workqueue is not frozen yet because ... it's not freezable :)
So could we queue to system_freezable_wq instead, or define our own freezable
workqueue there? Then a driver doesn't have to worry about that.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] virtio_mem: fix typo in comment
From: David Hildenbrand (Arm) @ 2026-07-14 8:44 UTC (permalink / raw)
To: weimin xiong, mst; +Cc: jasowangio, virtualization, xiongweimin
In-Reply-To: <20260714032417.201353-1-xiongwm2026@163.com>
On 7/14/26 05:24, weimin xiong wrote:
> From: xiongweimin <xiongweimin@kylinos.cn>
>
> Correct "actipn" to "action".
>
> Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
> ---
> drivers/virtio/virtio_mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 11c441501..90d8ef0b9 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb,
> atomic64_sub(size, &vm->offline_size);
> /*
> * Start adding more memory once we onlined half of our
> - * threshold. Don't trigger if it's possibly due to our actipn
> + * threshold. Don't trigger if it's possibly due to our action
> * (e.g., us adding memory which gets onlined immediately from
> * the core).
> */
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v1 20/20] gpio: Unify style of various *_device_id arrays
From: Andy Shevchenko @ 2026-07-14 8:37 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Linus Walleij, Bartosz Golaszewski, Lixu Zhang, Sakari Ailus,
Enrico Weigelt, metux IT consult, Viresh Kumar, Mika Westerberg,
linux-gpio, linux-kernel, virtualization, linux-acpi
In-Reply-To: <1f2d39342995533857417eb890628f7643b9a159.1784013063.git.u.kleine-koenig@baylibre.com>
On Tue, Jul 14, 2026 at 09:24:21AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Update the various *_device_id arrays to conform to the most used and
> generally recommended coding style. That is:
>
> - no comma after the list terminator;
> - a comma after an initializer if (and only if) the closing } is not
> directly following;
> - no explicit zeros in the list terminator;
> - a space after an opening { and before a closing }, a single space in
> the list terminator;
>
> Adapt the few offenders accordingly.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 20/20] gpio: Unify style of various *_device_id arrays
From: Sakari Ailus @ 2026-07-14 8:12 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Linus Walleij, Bartosz Golaszewski, Lixu Zhang,
Enrico Weigelt, metux IT consult, Viresh Kumar, Mika Westerberg,
Andy Shevchenko, linux-gpio, linux-kernel, virtualization,
linux-acpi
In-Reply-To: <1f2d39342995533857417eb890628f7643b9a159.1784013063.git.u.kleine-koenig@baylibre.com>
On Tue, Jul 14, 2026 at 09:24:21AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Update the various *_device_id arrays to conform to the most used and
> generally recommended coding style. That is:
>
> - no comma after the list terminator;
> - a comma after an initializer if (and only if) the closing } is not
> directly following;
> - no explicit zeros in the list terminator;
> - a space after an opening { and before a closing }, a single space in
> the list terminator;
>
> Adapt the few offenders accordingly.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/gpio/gpio-ljca.c | 2 +-
For gpio-ljca:
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v1 20/20] gpio: Unify style of various *_device_id arrays
From: Viresh Kumar @ 2026-07-14 8:10 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Linus Walleij, Bartosz Golaszewski, Lixu Zhang, Sakari Ailus,
Enrico Weigelt, metux IT consult, Viresh Kumar, Mika Westerberg,
Andy Shevchenko, linux-gpio, linux-kernel, virtualization,
linux-acpi
In-Reply-To: <1f2d39342995533857417eb890628f7643b9a159.1784013063.git.u.kleine-koenig@baylibre.com>
On 14-07-26, 09:24, Uwe Kleine-König (The Capable Hub) wrote:
> diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
> index 42871db05ec1..062c70fe4671 100644
> --- a/drivers/gpio/gpio-virtio.c
> +++ b/drivers/gpio/gpio-virtio.c
> @@ -647,7 +647,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
>
> static const struct virtio_device_id id_table[] = {
> { .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
> - {},
> + { }
> };
> MODULE_DEVICE_TABLE(virtio, id_table);
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v1 13/20] gpio: virtio: Use a named initializer for virtio_device_id array
From: Viresh Kumar @ 2026-07-14 8:10 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Linus Walleij, Bartosz Golaszewski,
Enrico Weigelt, metux IT consult, Viresh Kumar, linux-gpio,
virtualization, linux-kernel
In-Reply-To: <1f764e00e8cbe7624f4c9f3d8e5c368fd9a13e08.1784013063.git.u.kleine-koenig@baylibre.com>
On 14-07-26, 09:24, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> This patch doesn't modify the compiled array, only its representation in
> source form benefits.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/gpio/gpio-virtio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
> index ed6e0e90fa8a..42871db05ec1 100644
> --- a/drivers/gpio/gpio-virtio.c
> +++ b/drivers/gpio/gpio-virtio.c
> @@ -646,7 +646,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
> }
>
> static const struct virtio_device_id id_table[] = {
> - { VIRTIO_ID_GPIO, VIRTIO_DEV_ANY_ID },
> + { .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
> {},
> };
> MODULE_DEVICE_TABLE(virtio, id_table);
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v1 20/20] gpio: Unify style of various *_device_id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-14 7:24 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Lixu Zhang, Sakari Ailus, Enrico Weigelt, metux IT consult,
Viresh Kumar, Mika Westerberg, Andy Shevchenko, linux-gpio,
linux-kernel, virtualization, linux-acpi
In-Reply-To: <cover.1784013063.git.u.kleine-koenig@baylibre.com>
Update the various *_device_id arrays to conform to the most used and
generally recommended coding style. That is:
- no comma after the list terminator;
- a comma after an initializer if (and only if) the closing } is not
directly following;
- no explicit zeros in the list terminator;
- a space after an opening { and before a closing }, a single space in
the list terminator;
Adapt the few offenders accordingly.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/gpio/gpio-ljca.c | 2 +-
drivers/gpio/gpio-mpsse.c | 3 +--
drivers/gpio/gpio-pca953x.c | 2 +-
drivers/gpio/gpio-virtio.c | 2 +-
drivers/gpio/gpiolib-acpi-quirks.c | 2 +-
5 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-ljca.c b/drivers/gpio/gpio-ljca.c
index ad5dc9a3a119..d9d7394d8b95 100644
--- a/drivers/gpio/gpio-ljca.c
+++ b/drivers/gpio/gpio-ljca.c
@@ -473,7 +473,7 @@ static void ljca_gpio_remove(struct auxiliary_device *auxdev)
static const struct auxiliary_device_id ljca_gpio_id_table[] = {
{ "usb_ljca.ljca-gpio" },
- { /* sentinel */ },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(auxiliary, ljca_gpio_id_table);
diff --git a/drivers/gpio/gpio-mpsse.c b/drivers/gpio/gpio-mpsse.c
index a859deab2bca..7ca06bdb2c4b 100644
--- a/drivers/gpio/gpio-mpsse.c
+++ b/drivers/gpio/gpio-mpsse.c
@@ -77,10 +77,9 @@ static struct mpsse_quirk bryx_brik_quirk = {
static const struct usb_device_id gpio_mpsse_table[] = {
{ USB_DEVICE(0x0c52, 0xa064) }, /* SeaLevel Systems, Inc. */
{ USB_DEVICE(0x0403, 0x6988), /* FTDI, assigned to Bryx */
- .driver_info = (kernel_ulong_t)&bryx_brik_quirk},
+ .driver_info = (kernel_ulong_t)&bryx_brik_quirk },
{ } /* Terminating entry */
};
-
MODULE_DEVICE_TABLE(usb, gpio_mpsse_table);
static DEFINE_IDA(gpio_mpsse_ida);
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index a2d85ab1d01f..09d0a65382f5 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -175,7 +175,7 @@ static const struct dmi_system_id pca953x_dmi_acpi_irq_info[] = {
DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"),
},
},
- {}
+ { }
};
MODULE_DEVICE_TABLE(dmi, pca953x_dmi_acpi_irq_info);
#endif
diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index 42871db05ec1..062c70fe4671 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -647,7 +647,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
static const struct virtio_device_id id_table[] = {
{ .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
- {},
+ { }
};
MODULE_DEVICE_TABLE(virtio, id_table);
diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index 5525c467c21d..9bf5ba619107 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,7 +392,7 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
.ignore_wake = "VEN_0488:00@355",
},
},
- {} /* Terminating entry */
+ { } /* Terminating entry */
};
MODULE_DEVICE_TABLE(dmi, gpiolib_acpi_quirks);
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* [PATCH v1 13/20] gpio: virtio: Use a named initializer for virtio_device_id array
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-14 7:24 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Enrico Weigelt, metux IT consult, Viresh Kumar, linux-gpio,
virtualization, linux-kernel
In-Reply-To: <cover.1784013063.git.u.kleine-koenig@baylibre.com>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/gpio/gpio-virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index ed6e0e90fa8a..42871db05ec1 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -646,7 +646,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
}
static const struct virtio_device_id id_table[] = {
- { VIRTIO_ID_GPIO, VIRTIO_DEV_ANY_ID },
+ { .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
{},
};
MODULE_DEVICE_TABLE(virtio, id_table);
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* [PATCH v1 00/20] gpio: Improvements around device-id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-14 7:24 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Yang Shen, linux-gpio, linux-kernel, Lixu Zhang, Sakari Ailus,
Israel Cepeda, Hans de Goede, Andy Shevchenko, Ray Jui,
Broadcom internal kernel review list, Florian Fainelli,
Scott Branden, Eugeniy Paltsev, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Imre Kaloz, Conor Dooley,
Daire McNamara, Daniel Palmer, Romain Perier, Robert Jarzmik, imx,
linux-arm-kernel, linux-riscv, Mika Westerberg, Andy Shevchenko,
linux-acpi, Hoan Tran, Alan Borzeszkowski,
Enrico Weigelt, metux IT consult, Viresh Kumar, virtualization,
Yinbo Zhu, Thierry Reding, Jonathan Hunter, linux-tegra,
Geert Uytterhoeven, Adrian Ng, Joel Stanley, Andrew Jeffery,
Alban Bedel, James Cowgill, Matt Redfearn, Neil Jones,
Nikolaos Pasaloukos, Doug Berger, Keerthy, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Sven Peter, Janne Grunau, Neal Gompa,
Mathieu Dubois-Briand, André Draszik, Bamvor Jian Zhang,
Marek Behún, Matthias Brugger, AngeloGioacchino Del Regno,
Avi Fishman, Tomer Maimon, Tali Perry, Patrick Venture,
Nancy Yuen, Benjamin Fair, Grygorii Strashko, Santosh Shilimkar,
Kevin Hilman, Orson Zhai, Baolin Wang, Chunyan Zhang,
Manivannan Sadhasivam, Heiko Stuebner, Ludovic Desroches,
Paul Walmsley, Samuel Holland, Michael Walle, Maxime Coquelin,
Alexandre Torgue, Nobuhiro Iwamatsu, Shubhrajyoti Datta,
Srinivas Neeli, Michal Simek, Magnus Damm, linux-aspeed, asahi,
linux-mediatek, openbmc, linux-omap, linux-unisoc, linux-rockchip,
linux-stm32, linux-renesas-soc, Michael Buesch,
William Breathitt Gray, Robert Richter
Hello,
the original motivation for this series are the patches that convert the
arrays to use named initializers, see
https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
for the idea behind it. Then the quest grew, due to thinking to convert
all device id arrays in a single series to not bother each subsystem
repeatedly[1], then I spotted a few missing MODULE_DEVICE_TABLE annotations
and decided to fix these. Then I noticed that some driver_data entries
to be unused and then dropped them instead of converting to named
initializers. And as my scripts that do most of these changes also cared
about trailing commas and how the list terminators look, this is also
addressed in this series. And so this grew to 20 patches ...
This is based on yesterday's next and obviously merge window material.
Best regards
Uwe
[1] Of course this only works if no new entries are added that
initialize .driver_data by a positional initializer until I come
around to add the union to the respecive device id struct.
Uwe Kleine-König (The Capable Hub) (20):
gpio: Drop unused assignment of acpi_device_id driver data
gpio: max7301: Drop unused assignment of spi_device_id driver data
gpio: mmio: Drop unused assignment of platform_device_id driver data
gpio: ljca: Drop unused assignment of auxiliary_device_id driver data
gpio: Add missing ACPI module annotations
gpio: sodaville: Add missing pci module annotations
gpio: Add missing OF module annotations
gpio: pxa: Add missing platform module annotations
gpio: Add missing dmi module annotations
gpio: pl061: Use empty initializer for amba_id terminator
gpio: Use named initializers for acpi_device_id array
gpio: Use named initializers for spi_device_id array
gpio: virtio: Use a named initializer for virtio_device_id array
gpio: pcf857x: Use named initializers for of_device_id array
gpio: Unify style of acpi_device_id arrays
gpio: Unify style of of_device_id arrays
gpio: max77620: Unify style of platform_device_id arrays
gpio: Unify style of spi_device_id arrays
gpio: Unify style of pci_device_id arrays
gpio: Unify style of various *_device_id arrays
drivers/gpio/gpio-74x164.c | 4 ++--
drivers/gpio/gpio-adnp.c | 4 ++--
drivers/gpio/gpio-aggregator.c | 2 +-
drivers/gpio/gpio-altera-a10sr.c | 2 +-
drivers/gpio/gpio-altera.c | 4 ++--
drivers/gpio/gpio-amd8111.c | 2 +-
drivers/gpio/gpio-amdpt.c | 8 ++++----
drivers/gpio/gpio-aspeed-sgpio.c | 10 +++++-----
drivers/gpio/gpio-aspeed.c | 10 +++++-----
drivers/gpio/gpio-ath79.c | 2 +-
drivers/gpio/gpio-bcm-kona.c | 1 +
drivers/gpio/gpio-blzp1600.c | 2 +-
drivers/gpio/gpio-brcmstb.c | 2 +-
drivers/gpio/gpio-bt8xx.c | 2 +-
drivers/gpio/gpio-cadence.c | 4 ++--
drivers/gpio/gpio-creg-snps.c | 5 +++--
drivers/gpio/gpio-davinci.c | 6 +++---
drivers/gpio/gpio-dwapb.c | 14 +++++++-------
drivers/gpio/gpio-em.c | 4 ++--
drivers/gpio/gpio-ep93xx.c | 1 +
drivers/gpio/gpio-ftgpio010.c | 3 ++-
drivers/gpio/gpio-graniterapids.c | 4 ++--
drivers/gpio/gpio-grgpio.c | 2 +-
drivers/gpio/gpio-gw-pld.c | 4 ++--
drivers/gpio/gpio-hisi.c | 6 +++---
drivers/gpio/gpio-hlwd.c | 4 ++--
drivers/gpio/gpio-imx-scu.c | 1 +
drivers/gpio/gpio-ixp4xx.c | 4 ++--
drivers/gpio/gpio-ljca.c | 4 ++--
drivers/gpio/gpio-loongson-64bit.c | 4 ++--
drivers/gpio/gpio-lp3943.c | 2 +-
drivers/gpio/gpio-lpc32xx.c | 4 ++--
drivers/gpio/gpio-macsmc.c | 4 ++--
drivers/gpio/gpio-max3191x.c | 12 ++++++------
drivers/gpio/gpio-max7301.c | 2 +-
drivers/gpio/gpio-max7360.c | 8 ++++----
drivers/gpio/gpio-max77620.c | 4 ++--
drivers/gpio/gpio-max77759.c | 2 +-
drivers/gpio/gpio-mb86s7x.c | 2 +-
drivers/gpio/gpio-ml-ioh.c | 2 +-
drivers/gpio/gpio-mlxbf3.c | 4 ++--
drivers/gpio/gpio-mm-lantiq.c | 2 +-
drivers/gpio/gpio-mmio.c | 3 +--
drivers/gpio/gpio-mockup.c | 4 ++--
drivers/gpio/gpio-moxtet.c | 4 ++--
drivers/gpio/gpio-mpc5200.c | 5 +++--
drivers/gpio/gpio-mpc8xxx.c | 25 +++++++++++++------------
drivers/gpio/gpio-mpfs.c | 1 +
drivers/gpio/gpio-mpsse.c | 3 +--
drivers/gpio/gpio-msc313.c | 1 +
drivers/gpio/gpio-mt7621.c | 2 +-
drivers/gpio/gpio-mvebu.c | 1 +
drivers/gpio/gpio-mxc.c | 2 +-
drivers/gpio/gpio-mxs.c | 4 ++--
drivers/gpio/gpio-nomadik.c | 7 ++++---
drivers/gpio/gpio-novalake-events.c | 4 ++--
drivers/gpio/gpio-npcm-sgpio.c | 6 +++---
drivers/gpio/gpio-octeon.c | 2 +-
drivers/gpio/gpio-omap.c | 2 +-
drivers/gpio/gpio-palmas.c | 10 +++++-----
drivers/gpio/gpio-pca953x.c | 3 ++-
drivers/gpio/gpio-pca9570.c | 2 +-
drivers/gpio/gpio-pcf857x.c | 26 +++++++++++++-------------
drivers/gpio/gpio-pci-idio-16.c | 3 ++-
drivers/gpio/gpio-pcie-idio-24.c | 8 +++++---
drivers/gpio/gpio-pisosr.c | 4 ++--
drivers/gpio/gpio-pl061.c | 2 +-
drivers/gpio/gpio-pmic-eic-sprd.c | 2 +-
drivers/gpio/gpio-pxa.c | 20 +++++++++++---------
drivers/gpio/gpio-qixis-fpga.c | 3 +--
drivers/gpio/gpio-rda.c | 2 +-
drivers/gpio/gpio-realtek-otto.c | 2 +-
drivers/gpio/gpio-rockchip.c | 4 ++--
drivers/gpio/gpio-sama5d2-piobu.c | 2 +-
drivers/gpio/gpio-sifive.c | 2 +-
drivers/gpio/gpio-sl28cpld.c | 2 +-
drivers/gpio/gpio-sodaville.c | 3 ++-
drivers/gpio/gpio-spear-spics.c | 3 ++-
drivers/gpio/gpio-sprd.c | 2 +-
drivers/gpio/gpio-stmpe.c | 2 +-
drivers/gpio/gpio-stp-xway.c | 2 +-
drivers/gpio/gpio-tegra.c | 2 +-
drivers/gpio/gpio-tegra186.c | 2 +-
drivers/gpio/gpio-thunderx.c | 3 +--
drivers/gpio/gpio-tps65218.c | 2 +-
drivers/gpio/gpio-ts4800.c | 4 ++--
drivers/gpio/gpio-twl4030.c | 4 ++--
drivers/gpio/gpio-usbio.c | 13 +++++++------
drivers/gpio/gpio-vf610.c | 4 ++--
drivers/gpio/gpio-virtio.c | 4 ++--
drivers/gpio/gpio-visconti.c | 2 +-
drivers/gpio/gpio-waveshare-dsi.c | 2 +-
drivers/gpio/gpio-xgene-sb.c | 6 +++---
drivers/gpio/gpio-xgene.c | 10 ++++++----
drivers/gpio/gpio-xgs-iproc.c | 2 +-
drivers/gpio/gpio-xilinx.c | 2 +-
drivers/gpio/gpio-xlp.c | 6 +++---
drivers/gpio/gpio-xra1403.c | 6 +++---
drivers/gpio/gpio-zevio.c | 5 +++--
drivers/gpio/gpio-zynqmp-modepin.c | 2 +-
drivers/gpio/gpiolib-acpi-quirks.c | 3 ++-
101 files changed, 231 insertions(+), 211 deletions(-)
base-commit: 49362394dad7df66c274c867a271394c10ca2bb8
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply
* Re:RE: [PATCH] virtio_mem: fix typo in comment
From: xiongwm2026 @ 2026-07-14 6:00 UTC (permalink / raw)
To: Parav Pandit
Cc: mst@redhat.com, jasowangio@gmail.com, david@redhat.com,
virtualization@lists.linux.dev, xiongweimin
In-Reply-To: <SJ0PR12MB6806262FB6F99ADA13EC127CDCF92@SJ0PR12MB6806.namprd12.prod.outlook.com>
Hi Parav,
Thanks for the review!
Best regards,
Weimin
At 2026-07-14 12:27:45, "Parav Pandit" <parav@nvidia.com> wrote:
>
>
>> From: weimin xiong <xiongwm2026@163.com>
>> Sent: 14 July 2026 08:54 AM
>>
>> [You don't often get email from xiongwm2026@163.com. Learn why this is important at
>> https://aka.ms/LearnAboutSenderIdentification ]
>
>>
>> From: xiongweimin <xiongweimin@kylinos.cn>
>>
>> Correct "actipn" to "action".
>>
>> Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
>> ---
>> drivers/virtio/virtio_mem.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
>> index 11c441501..90d8ef0b9 100644
>> --- a/drivers/virtio/virtio_mem.c
>> +++ b/drivers/virtio/virtio_mem.c
>> @@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb,
>> atomic64_sub(size, &vm->offline_size);
>> /*
>> * Start adding more memory once we onlined half of our
>> - * threshold. Don't trigger if it's possibly due to our actipn
>> + * threshold. Don't trigger if it's possibly due to our action
>> * (e.g., us adding memory which gets onlined immediately from
>> * the core).
>> */
>> --
>> 2.43.0
>>
>>
>> No virus found
>> Checked by Hillstone Network AntiVirus
>>
>
>Reviewed-by: Parav Pandit <parav@nvidia.com>
^ permalink raw reply
* RE: [PATCH] virtio_mem: fix typo in comment
From: Parav Pandit @ 2026-07-14 4:27 UTC (permalink / raw)
To: weimin xiong, mst@redhat.com
Cc: jasowangio@gmail.com, david@redhat.com,
virtualization@lists.linux.dev, xiongweimin
In-Reply-To: <20260714032417.201353-1-xiongwm2026@163.com>
> From: weimin xiong <xiongwm2026@163.com>
> Sent: 14 July 2026 08:54 AM
>
> [You don't often get email from xiongwm2026@163.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> From: xiongweimin <xiongweimin@kylinos.cn>
>
> Correct "actipn" to "action".
>
> Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
> ---
> drivers/virtio/virtio_mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 11c441501..90d8ef0b9 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb,
> atomic64_sub(size, &vm->offline_size);
> /*
> * Start adding more memory once we onlined half of our
> - * threshold. Don't trigger if it's possibly due to our actipn
> + * threshold. Don't trigger if it's possibly due to our action
> * (e.g., us adding memory which gets onlined immediately from
> * the core).
> */
> --
> 2.43.0
>
>
> No virus found
> Checked by Hillstone Network AntiVirus
>
Reviewed-by: Parav Pandit <parav@nvidia.com>
^ permalink raw reply
* [PATCH] virtio_mem: fix typo in comment
From: weimin xiong @ 2026-07-14 3:24 UTC (permalink / raw)
To: mst; +Cc: jasowangio, david, virtualization, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Correct "actipn" to "action".
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/virtio/virtio_mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 11c441501..90d8ef0b9 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb,
atomic64_sub(size, &vm->offline_size);
/*
* Start adding more memory once we onlined half of our
- * threshold. Don't trigger if it's possibly due to our actipn
+ * threshold. Don't trigger if it's possibly due to our action
* (e.g., us adding memory which gets onlined immediately from
* the core).
*/
--
2.43.0
No virus found
Checked by Hillstone Network AntiVirus
^ permalink raw reply related
* [PATCH v1 1/2] iommu/virtio: Set driver data before enabling virtqueues
From: weimin xiong @ 2026-07-14 2:59 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714025914.193580-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
The event virtqueue callback retrieves the driver state through
vq->vdev->priv. viommu_probe() currently initializes that pointer only
after virtio_device_ready() and after the event queue is populated.
Store the driver data before creating the virtqueues so callbacks always
see initialized driver state once the device is made ready. Clear the
pointer again on probe failure.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 9118377d7..4c91a82d2 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1173,11 +1173,12 @@ static int viommu_probe(struct virtio_device *vdev)
ida_init(&viommu->domain_ids);
viommu->dev = dev;
viommu->vdev = vdev;
+ vdev->priv = viommu;
INIT_LIST_HEAD(&viommu->requests);
ret = viommu_init_vqs(viommu);
if (ret)
- return ret;
+ goto err_clear_priv;
virtio_cread_le(vdev, struct virtio_iommu_config, page_size_mask,
&viommu->pgsize_bitmap);
@@ -1238,8 +1239,6 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
- vdev->priv = viommu;
-
ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
if (ret)
goto err_remove_sysfs;
@@ -1254,6 +1253,7 @@ static int viommu_probe(struct virtio_device *vdev)
iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+err_clear_priv:
vdev->priv = NULL;
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/2] iommu/virtio: Harden event handling
From: weimin xiong @ 2026-07-14 2:59 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
From: Xiong Weimin <xiongweimin@kylinos.cn>
Hi,
This follow-up series hardens virtio-iommu event handling.
It is based on the probe error handling fixes sent earlier:
[PATCH v1 0/2] iommu/virtio: Fix probe error handling
Message-ID: <20260714024949.190014-1-15927021679@163.com>
The first patch makes sure vq->vdev->priv is initialized before
virtqueues can invoke callbacks. The second patch rejects short event
buffers before reading the event contents.
Xiong Weimin (2):
iommu/virtio: Set driver data before enabling virtqueues
iommu/virtio: Reject short event buffers
drivers/iommu/virtio-iommu.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v1 2/2] iommu/virtio: Reject short event buffers
From: weimin xiong @ 2026-07-14 2:59 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714025914.193580-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
viommu_event_handler() only rejects event buffers that are larger than
struct viommu_event. A short buffer is also invalid, but the handler
would still read evt->head and, for fault events, the rest of evt->fault.
Require the used length to match the event buffer size before looking at
the event contents.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 4c91a82d2..4b7f0dcfa 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -635,7 +635,7 @@ static void viommu_event_handler(struct virtqueue *vq)
struct viommu_dev *viommu = vq->vdev->priv;
while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
- if (len > sizeof(*evt)) {
+ if (len != sizeof(*evt)) {
dev_err(viommu->dev,
"invalid event buffer (len %u != %zu)\n",
len, sizeof(*evt));
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/2] iommu/virtio: Avoid use-after-put in viommu_get_by_fwnode
From: weimin xiong @ 2026-07-14 2:49 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714024949.190014-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
bus_find_device() returns a device reference that must be released with
put_device(). viommu_get_by_fwnode() currently drops that reference
before dereferencing the device to fetch the virtio-IOMMU private data.
Fetch the private data while the reference is still held, then release
the device reference before returning.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..342785c76 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1009,12 +1009,16 @@ static int viommu_match_node(struct device *dev, const void *data)
static struct viommu_dev *viommu_get_by_fwnode(struct fwnode_handle *fwnode)
{
+ struct viommu_dev *viommu = NULL;
struct device *dev = bus_find_device(virtio_bus_type, NULL, fwnode,
viommu_match_node);
- put_device(dev);
+ if (dev) {
+ viommu = dev_to_virtio(dev)->priv;
+ put_device(dev);
+ }
- return dev ? dev_to_virtio(dev)->priv : NULL;
+ return viommu;
}
static struct iommu_device *viommu_probe_device(struct device *dev)
--
2.43.0
^ permalink raw reply related
* [PATCH v1 2/2] iommu/virtio: Handle iommu_device_register() failures
From: weimin xiong @ 2026-07-14 2:49 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714024949.190014-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
iommu_device_register() returns an error when the IOMMU core fails to
register the hardware instance or probe the buses. viommu_probe()
currently ignores that error and continues as if the device was
registered successfully.
Propagate the failure and unwind the sysfs entry and virtqueues that
were set up earlier. Clear the driver data on the error path as well,
since it is set before registration so bus probing can find the
virtio-IOMMU instance.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 342785c76..9118377d7 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1240,7 +1240,9 @@ static int viommu_probe(struct virtio_device *vdev)
vdev->priv = viommu;
- iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ if (ret)
+ goto err_remove_sysfs;
dev_info(dev, "input address: %u bits\n",
order_base_2(viommu->geometry.aperture_end));
@@ -1248,8 +1250,11 @@ static int viommu_probe(struct virtio_device *vdev)
return 0;
+err_remove_sysfs:
+ iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+ vdev->priv = NULL;
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/2] iommu/virtio: Fix probe error handling
From: weimin xiong @ 2026-07-14 2:49 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
From: Xiong Weimin <xiongweimin@kylinos.cn>
Hi,
This small series fixes two probe-time error handling issues in the
virtio-iommu driver.
The first patch avoids dereferencing a device after dropping the
reference returned by bus_find_device(). The second patch propagates
failures from iommu_device_register() and unwinds the resources that
were set up earlier in probe.
Xiong Weimin (2):
iommu/virtio: Avoid use-after-put in viommu_get_by_fwnode
iommu/virtio: Handle iommu_device_register() failures
drivers/iommu/virtio-iommu.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 12/13] mm/mprotect: convert mprotect code to use vma_flags_t
From: Zi Yan @ 2026-07-14 2:46 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, David Hildenbrand, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau, linux-mm, linux-kernel, linux-mips,
linux-aio, linux-fsdevel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-12-0fa2357d5431@kernel.org>
On 11 Jul 2026, at 14:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mprotect logic.
>
> Note that we retain the legacy vm_flags_t bit shifting code in
> do_mprotect_pkey(), deferring a vma_flags_t approach to this for the time
> being.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/mprotect.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* [PATCH] vdpa/solidrun: fix typos in snet_ctrl comments
From: weimin xiong @ 2026-07-14 2:45 UTC (permalink / raw)
To: virtualization
Cc: alvaro.karsz, mst, jasowangio, xuanzhuo, eperezma, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Correct "readind" and "the an error" in the DPU control path comments.
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/vdpa/solidrun/snet_ctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/solidrun/snet_ctrl.c b/drivers/vdpa/solidrun/snet_ctrl.c
index 3cef2571d..e284c3a06 100644
--- a/drivers/vdpa/solidrun/snet_ctrl.c
+++ b/drivers/vdpa/solidrun/snet_ctrl.c
@@ -124,10 +124,10 @@ static int snet_wait_for_dpu_completion(struct snet_ctrl_regs __iomem *ctrl_regs
* reading the in_process and error bits in the control register.
* (2) Write the request opcode and the VQ idx in the opcode register
* and write the buffer size in the control register.
- * (3) Start readind chunks of data, chunk_ready bit indicates that a
+ * (3) Start reading chunks of data, chunk_ready bit indicates that a
* data chunk is available, we signal that we read the data by clearing the bit.
* (4) Detect that the transfer is completed when the in_process bit
- * in the control register is cleared or when the an error appears.
+ * in the control register is cleared or when an error appears.
*/
static int snet_ctrl_read_from_dpu(struct snet *snet, u16 opcode, u16 vq_idx, void *buffer,
u32 buf_size)
--
2.43.0
No virus found
Checked by Hillstone Network AntiVirus
^ permalink raw reply related
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