* Re: [RFC PATCH v1] virtio_pci: only store successfully populated virtio_pci_vq_info
From: Michael S. Tsirkin @ 2026-04-26 14:57 UTC (permalink / raw)
To: Ammar Faizi
Cc: Link Lin, jasowang, xuanzhuo, eperezma, jiaqiyan, rientjes,
weixugc, virtualization, linux-kernel
In-Reply-To: <CA+KFgX68PJqhHg1-DHwxEZVj_Dn7m4jqUHUnuvWyQajDrkZV2g@mail.gmail.com>
On Sun, Apr 26, 2026 at 09:28:15PM +0700, Ammar Faizi wrote:
> On Wed, Apr 22, 2026 at 5:16 AM Michael S. Tsirkin wrote:
> > On Tue, Apr 21, 2026 at 03:15:55PM -0700, Link Lin wrote:
> > > Quick follow-up question: Do you know if this will make it into v7.1?
> >
> > I'll try.
>
> It seems it's already too late for the 7.1 merge window. Maybe 7.2?
>
> --
> Ammar Faizi
It's a bugfix, no? never late.
^ permalink raw reply
* Re: [RFC PATCH v1] virtio_pci: only store successfully populated virtio_pci_vq_info
From: Ammar Faizi @ 2026-04-26 14:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Link Lin, jasowang, xuanzhuo, eperezma, jiaqiyan, rientjes,
weixugc, virtualization, linux-kernel
In-Reply-To: <20260421181640-mutt-send-email-mst@kernel.org>
On Wed, Apr 22, 2026 at 5:16 AM Michael S. Tsirkin wrote:
> On Tue, Apr 21, 2026 at 03:15:55PM -0700, Link Lin wrote:
> > Quick follow-up question: Do you know if this will make it into v7.1?
>
> I'll try.
It seems it's already too late for the 7.1 merge window. Maybe 7.2?
--
Ammar Faizi
^ permalink raw reply
* Re: [PATCH v2 3/3] vfio/pci: Check BAR resources before exporting a DMABUF
From: Leon Romanovsky @ 2026-04-26 11:16 UTC (permalink / raw)
To: Matt Evans
Cc: Alex Williamson, Kevin Tian, Jason Gunthorpe, Ankit Agrawal,
Alistair Popple, Kees Cook, Shameer Kolothum, Yishai Hadas,
Alexey Kardashevskiy, Eric Auger, Peter Xu, Vivek Kasireddy,
Zhi Wang, kvm, linux-kernel, virtualization
In-Reply-To: <20260423182517.2286030-4-mattev@meta.com>
On Thu, Apr 23, 2026 at 11:25:09AM -0700, Matt Evans wrote:
> A DMABUF exports access to BAR resources and, although they are
> requested at startup time, we need to ensure they really were reserved
> before exporting. Otherwise, it's possible to access unreserved
> resources through the export.
>
> Add a check to the DMABUF-creation path.
>
> Fixes: 5d74781ebc86c ("vfio/pci: Add dma-buf export support for MMIO regions")
> Signed-off-by: Matt Evans <mattev@meta.com>
> ---
> drivers/vfio/pci/vfio_pci_dmabuf.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] vfio/pci: Replace vfio_pci_core_setup_barmap() with checks for resource/map
From: Leon Romanovsky @ 2026-04-26 11:05 UTC (permalink / raw)
To: Matt Evans
Cc: Alex Williamson, Kevin Tian, Jason Gunthorpe, Ankit Agrawal,
Alistair Popple, Kees Cook, Shameer Kolothum, Yishai Hadas,
Alexey Kardashevskiy, Eric Auger, Peter Xu, Vivek Kasireddy,
Zhi Wang, kvm, linux-kernel, virtualization
In-Reply-To: <20260423182517.2286030-3-mattev@meta.com>
On Thu, Apr 23, 2026 at 11:25:08AM -0700, Matt Evans wrote:
> Since "vfio/pci: Set up barmap in vfio_pci_core_enable()", the
> resource request and iomap for the BARs was performed early, and
> vfio_pci_core_setup_barmap() now just checks those actions succeeded.
>
> There were two types of callers:
> - Those that need the iomap, because they'll access the BAR
> - Those that need the resource, because they'll map/export it
>
> This replaces vfio_pci_core_setup_barmap() with two helpers,
> vfio_pci_core_check_barmap_valid() and vfio_pci_core_check_bar_rsrc(),
> to make it clear which behaviour is required in each caller.
>
> Signed-off-by: Matt Evans <mattev@meta.com>
> ---
> drivers/vfio/pci/nvgrace-gpu/main.c | 8 +++-----
> drivers/vfio/pci/vfio_pci_core.c | 5 ++---
> drivers/vfio/pci/vfio_pci_rdwr.c | 22 ++--------------------
> drivers/vfio/pci/virtio/legacy_io.c | 4 ++--
> include/linux/vfio_pci_core.h | 23 ++++++++++++++++++++++-
> 5 files changed, 31 insertions(+), 31 deletions(-)
<...>
> +/* Returns 0 if vdev->barmap[bar] can be accessed, otherwise errno */
> +static inline int
> +vfio_pci_core_check_barmap_valid(struct vfio_pci_core_device *vdev, int bar)
> +{
> + if (bar < 0 || bar >= PCI_STD_NUM_BARS)
> + return -EINVAL;
> + if (vdev->barmap[bar] == 0)
I understand this line was copied from an earlier implementation, but
barmap[bar] is a pointer, and it is set to NULL when it is released.
if (!dev->barmap[bar])
return -ENOMEM;
Thanks
> + return -ENOMEM;
> + return 0;
> +}
> +
> +/* Returns 0 if BAR has a valid resource reserved for use, otherwise errno */
> +static inline int vfio_pci_core_check_bar_rsrc(struct vfio_pci_core_device *vdev,
> + int bar)
> +{
> + if (bar < 0 || bar >= PCI_STD_NUM_BARS)
> + return -EINVAL;
> + if (!vdev->have_bar_resource[bar])
> + return -EBUSY;
> + return 0;
> +}
> +
> static inline bool is_aligned_for_order(struct vm_area_struct *vma,
> unsigned long addr,
> unsigned long pfn,
> --
> 2.47.3
>
^ permalink raw reply
* RE: [PATCH 2/2] drm/hyperv: use VMBUS_RING_SIZE()
From: Saurabh Singh Sengar @ 2026-04-26 5:00 UTC (permalink / raw)
To: Hamza Mahfooz, linux-kernel@vger.kernel.org
Cc: KY Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Stefano Garzarella, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Himadri Pandya, Michael Kelley,
linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
netdev@vger.kernel.org, Saurabh Sengar, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Deepak Rawat, dri-devel@lists.freedesktop.org,
stable@kernel.vger.org
In-Reply-To: <20260425181719.1538483-2-hamzamahfooz@linux.microsoft.com>
> Subject: [PATCH 2/2] drm/hyperv: use VMBUS_RING_SIZE()
>
> VMBUS ring buffers must be page aligned. So, use VMBUS_RING_SIZE() to
> ensure they are always aligned and large enough to hold all of the relevant
> data.
>
> Cc: stable@kernel.vger.org
> Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video
> device")
> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
> ---
> drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> index 051ecc526832..753d97bff76f 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> @@ -10,7 +10,7 @@
>
> #include "hyperv_drm.h"
>
> -#define VMBUS_RING_BUFSIZE (256 * 1024)
> +#define VMBUS_RING_BUFSIZE VMBUS_RING_SIZE(256 * 1024)
> #define VMBUS_VSP_TIMEOUT (10 * HZ)
>
> #define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
> --
> 2.54.0
Although this lgtm, but this may change the behaviour on ARM64 systems with page size > 4K ?
Have we tested it ?
Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
^ permalink raw reply
* [PATCH 2/2] drm/hyperv: use VMBUS_RING_SIZE()
From: Hamza Mahfooz @ 2026-04-25 18:17 UTC (permalink / raw)
To: linux-kernel
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Stefano Garzarella, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Himadri Pandya, Michael Kelley,
linux-hyperv, virtualization, netdev, Saurabh Sengar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Deepak Rawat, dri-devel, Hamza Mahfooz, stable
In-Reply-To: <20260425181719.1538483-1-hamzamahfooz@linux.microsoft.com>
VMBUS ring buffers must be page aligned. So, use VMBUS_RING_SIZE() to
ensure they are always aligned and large enough to hold all of the
relevant data.
Cc: stable@kernel.vger.org
Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device")
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
index 051ecc526832..753d97bff76f 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
@@ -10,7 +10,7 @@
#include "hyperv_drm.h"
-#define VMBUS_RING_BUFSIZE (256 * 1024)
+#define VMBUS_RING_BUFSIZE VMBUS_RING_SIZE(256 * 1024)
#define VMBUS_VSP_TIMEOUT (10 * HZ)
#define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] hv_sock: fix ARM64 support
From: Hamza Mahfooz @ 2026-04-25 18:17 UTC (permalink / raw)
To: linux-kernel
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Stefano Garzarella, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Himadri Pandya, Michael Kelley,
linux-hyperv, virtualization, netdev, Saurabh Sengar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Deepak Rawat, dri-devel, Hamza Mahfooz, stable
VMBUS ring buffers must be page aligned. Therefore, the current value of
24K presents a challenge on ARM64 kernels (with 64K pages). So, use
VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
hold all of the relevant data.
Cc: stable@kernel.vger.org
Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication")
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
net/vmw_vsock/hyperv_transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 069386a74557..40f09b23efa3 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -375,10 +375,10 @@ static void hvs_open_connection(struct vmbus_channel *chan)
} else {
sndbuf = max_t(int, sk->sk_sndbuf, RINGBUFFER_HVS_SND_SIZE);
sndbuf = min_t(int, sndbuf, RINGBUFFER_HVS_MAX_SIZE);
- sndbuf = ALIGN(sndbuf, HV_HYP_PAGE_SIZE);
+ sndbuf = VMBUS_RING_SIZE(sndbuf);
rcvbuf = max_t(int, sk->sk_rcvbuf, RINGBUFFER_HVS_RCV_SIZE);
rcvbuf = min_t(int, rcvbuf, RINGBUFFER_HVS_MAX_SIZE);
- rcvbuf = ALIGN(rcvbuf, HV_HYP_PAGE_SIZE);
+ rcvbuf = VMBUS_RING_SIZE(rcvbuf);
}
chan->max_pkt_size = HVS_MAX_PKT_SIZE;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] virtio: rtc: tear down old virtqueues before restore
From: Michael S. Tsirkin @ 2026-04-25 17:03 UTC (permalink / raw)
To: Jia Jia
Cc: Peter Hilber, jasowang, xuanzhuo, eperezma, virtualization,
linux-kernel
In-Reply-To: <20260425160906.677660-1-physicalmtea@gmail.com>
On Sun, Apr 26, 2026 at 12:09:06AM +0800, Jia Jia wrote:
> Hi Michael,
>
> JiaJia is my full name. My family name is Jia and my given name is also Jia.
>
> I wrote it as "JiaJia", but "Jia Jia" is probably clearer. I will use "Jia Jia"
> in future postings.
>
> Thanks,
> Jia Jia
Beautiful. Yes, clearer, thank you so much.
--
MST
^ permalink raw reply
* Re: [PATCH v3] virtio: rtc: tear down old virtqueues before restore
From: Jia Jia @ 2026-04-25 16:09 UTC (permalink / raw)
To: Michael S . Tsirkin
Cc: Peter Hilber, jasowang, xuanzhuo, eperezma, virtualization,
linux-kernel
In-Reply-To: <20260425110857-mutt-send-email-mst@kernel.org>
Hi Michael,
JiaJia is my full name. My family name is Jia and my given name is also Jia.
I wrote it as "JiaJia", but "Jia Jia" is probably clearer. I will use "Jia Jia"
in future postings.
Thanks,
Jia Jia
^ permalink raw reply
* Re: [PATCH v3] virtio: rtc: tear down old virtqueues before restore
From: Michael S. Tsirkin @ 2026-04-25 15:10 UTC (permalink / raw)
To: physicalmtea
Cc: Peter Hilber, jasowang, xuanzhuo, eperezma, virtualization,
linux-kernel
In-Reply-To: <20260425070840.488634-1-physicalmtea@gmail.com>
On Sat, Apr 25, 2026 at 03:08:40PM +0800, physicalmtea wrote:
> From: JiaJia <physicalmtea@gmail.com>
>
> virtio_device_restore() resets the device and restores the negotiated
> features before calling ->restore(). viortc_freeze() intentionally
> leaves the existing virtqueues in place so the alarm queue can still
> wake the system, but viortc_restore() immediately calls
> viortc_init_vqs() without first deleting those old queues.
>
> If virtqueue reinitialization fails on virtio-pci, the transport error
> path can run vp_del_vqs() against a newly allocated vp_dev->vqs array
> while vdev->vqs still contains the old virtqueues. vp_del_vqs() then
> looks up queue state through the new array and can dereference a NULL
> info pointer in vp_del_vq(), crashing the guest kernel during restore.
>
> This can also happen during a non-faulty reinitialization, when one of
> the vp_find_vqs_msix() attempts is unsuccessful before a later attempt
> would succeed.
>
> Delete the stale virtqueues before rebuilding them. If restore fails
> before virtio_device_ready(), reuse the remove path to stop the device.
> Once the device is ready, return errors directly instead of deleting the
> virtqueues again.
>
> Fixes: 0623c7592768 ("virtio_rtc: Add module and driver core")
> Signed-off-by: JiaJia <physicalmtea@gmail.com>
Sorry is this just the 1st name or the 1st and the last name?
I think it's preferred to have the full name here.
> Reviewed-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> ---
> v3:
> - Add Fixes tag.
> - Add Peter's Reviewed-by tag.
> - Clarify commit message regarding reinitialization scenarios.
>
> Apologies for missing the Fixes tag, and thanks for catching that!
> I've also updated the commit message to include the scenario you
> mentioned.
>
> drivers/virtio/virtio_rtc_driver.c | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/virtio/virtio_rtc_driver.c b/drivers/virtio/virtio_rtc_driver.c
> index a57d5e06e..4419735b0 100644
> --- a/drivers/virtio/virtio_rtc_driver.c
> +++ b/drivers/virtio/virtio_rtc_driver.c
> @@ -1257,6 +1257,15 @@ static int viortc_init_vqs(struct viortc_dev *viortc)
> return 0;
> }
>
> +static void __viortc_remove(struct viortc_dev *viortc)
> +{
> + struct virtio_device *vdev = viortc->vdev;
> +
> + viortc_clocks_deinit(viortc);
> + virtio_reset_device(vdev);
> + vdev->config->del_vqs(vdev);
> +}
> +
> /**
> * viortc_probe() - probe a virtio_rtc virtio device
> * @vdev: virtio device
> @@ -1282,7 +1291,7 @@ static int viortc_probe(struct virtio_device *vdev)
>
> ret = viortc_init_vqs(viortc);
> if (ret)
> - return ret;
> + goto err_reset_vdev;
>
> virtio_device_ready(vdev);
>
> @@ -1329,10 +1338,7 @@ static void viortc_remove(struct virtio_device *vdev)
> {
> struct viortc_dev *viortc = vdev->priv;
>
> - viortc_clocks_deinit(viortc);
> -
> - virtio_reset_device(vdev);
> - vdev->config->del_vqs(vdev);
> + __viortc_remove(viortc);
> }
>
> static int viortc_freeze(struct virtio_device *dev)
> @@ -1353,9 +1359,11 @@ static int viortc_restore(struct virtio_device *dev)
> bool notify = false;
> int ret;
>
> + dev->config->del_vqs(dev);
> +
> ret = viortc_init_vqs(viortc);
> if (ret)
> - return ret;
> + goto err_remove;
>
> alarm_viortc_vq = &viortc->vqs[VIORTC_ALARMQ];
> alarm_vq = alarm_viortc_vq->vq;
> @@ -1364,7 +1372,7 @@ static int viortc_restore(struct virtio_device *dev)
> ret = viortc_populate_vq(viortc, alarm_viortc_vq,
> VIORTC_ALARMQ_BUF_CAP, false);
> if (ret)
> - return ret;
> + goto err_remove;
>
> notify = virtqueue_kick_prepare(alarm_vq);
> }
> @@ -1372,8 +1380,12 @@ static int viortc_restore(struct virtio_device *dev)
> virtio_device_ready(dev);
>
> if (notify && !virtqueue_notify(alarm_vq))
> - ret = -EIO;
> + return -EIO;
> +
> + return 0;
>
> +err_remove:
> + __viortc_remove(viortc);
> return ret;
> }
>
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Andrew Morton @ 2026-04-25 11:36 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Yosry Ahmed, Pasha Tatashin, Lance Yang, peterz, dave.hansen,
dave.hansen, ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx,
mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett,
npache, ryan.roberts, dev.jain, baohua, shy828301, riel, jannh,
jgross, seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <872e752d-c7fa-4a75-a963-4e2f42ce468b@kernel.org>
On Sat, 25 Apr 2026 07:17:18 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > The usefulness of the mailing list posting is that it makes it easier
> > to respond and discuss the review. Yes, what Zi did is great, but it
> > would be nice if contributors/reviewers didn't need to manually quote
> > Sashiko.
>
> I think the most important part is the contributor side. A private posting is
> sufficient for that.
Thinking through how is this going to work out.
- contributor sends patchset
- akpm looks at the Sashiko scan and thinks "huh, we might be seeing
a new version soon".
- Now what? Maybe contributor doesn't like AI, maybe contributor
thinks it was all nonsense. But I don't know this!
So I send the email "I see that Sashiko said stuff - can we expect
a new version?". Which is no improvement over what's happening now.
What I would like to have is some reasonably reliable and prompt means
by which we all learn contributor's views on the Sashiko scan.
One way to bring this about might be to set suitable reply-to headers
in the Sashiko->contributor email, along with a few words asking
contributor to let everyone know the status.
But whatever - let's not overthink this. To start somewhere, let's
send that private email, spend a few weeks evaluating then perhaps make
adjustments.
^ permalink raw reply
* [PATCH v3] virtio: rtc: tear down old virtqueues before restore
From: physicalmtea @ 2026-04-25 7:08 UTC (permalink / raw)
To: Peter Hilber
Cc: mst, jasowang, xuanzhuo, eperezma, virtualization, linux-kernel,
JiaJia
In-Reply-To: <d2gtdzjz3bfs47rmeslo46dkwmjqpv2qjcxmpgbkcbxjrqbf6m@bkeeynnavvy3>
From: JiaJia <physicalmtea@gmail.com>
virtio_device_restore() resets the device and restores the negotiated
features before calling ->restore(). viortc_freeze() intentionally
leaves the existing virtqueues in place so the alarm queue can still
wake the system, but viortc_restore() immediately calls
viortc_init_vqs() without first deleting those old queues.
If virtqueue reinitialization fails on virtio-pci, the transport error
path can run vp_del_vqs() against a newly allocated vp_dev->vqs array
while vdev->vqs still contains the old virtqueues. vp_del_vqs() then
looks up queue state through the new array and can dereference a NULL
info pointer in vp_del_vq(), crashing the guest kernel during restore.
This can also happen during a non-faulty reinitialization, when one of
the vp_find_vqs_msix() attempts is unsuccessful before a later attempt
would succeed.
Delete the stale virtqueues before rebuilding them. If restore fails
before virtio_device_ready(), reuse the remove path to stop the device.
Once the device is ready, return errors directly instead of deleting the
virtqueues again.
Fixes: 0623c7592768 ("virtio_rtc: Add module and driver core")
Signed-off-by: JiaJia <physicalmtea@gmail.com>
Reviewed-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
---
v3:
- Add Fixes tag.
- Add Peter's Reviewed-by tag.
- Clarify commit message regarding reinitialization scenarios.
Apologies for missing the Fixes tag, and thanks for catching that!
I've also updated the commit message to include the scenario you
mentioned.
drivers/virtio/virtio_rtc_driver.c | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/virtio/virtio_rtc_driver.c b/drivers/virtio/virtio_rtc_driver.c
index a57d5e06e..4419735b0 100644
--- a/drivers/virtio/virtio_rtc_driver.c
+++ b/drivers/virtio/virtio_rtc_driver.c
@@ -1257,6 +1257,15 @@ static int viortc_init_vqs(struct viortc_dev *viortc)
return 0;
}
+static void __viortc_remove(struct viortc_dev *viortc)
+{
+ struct virtio_device *vdev = viortc->vdev;
+
+ viortc_clocks_deinit(viortc);
+ virtio_reset_device(vdev);
+ vdev->config->del_vqs(vdev);
+}
+
/**
* viortc_probe() - probe a virtio_rtc virtio device
* @vdev: virtio device
@@ -1282,7 +1291,7 @@ static int viortc_probe(struct virtio_device *vdev)
ret = viortc_init_vqs(viortc);
if (ret)
- return ret;
+ goto err_reset_vdev;
virtio_device_ready(vdev);
@@ -1329,10 +1338,7 @@ static void viortc_remove(struct virtio_device *vdev)
{
struct viortc_dev *viortc = vdev->priv;
- viortc_clocks_deinit(viortc);
-
- virtio_reset_device(vdev);
- vdev->config->del_vqs(vdev);
+ __viortc_remove(viortc);
}
static int viortc_freeze(struct virtio_device *dev)
@@ -1353,9 +1359,11 @@ static int viortc_restore(struct virtio_device *dev)
bool notify = false;
int ret;
+ dev->config->del_vqs(dev);
+
ret = viortc_init_vqs(viortc);
if (ret)
- return ret;
+ goto err_remove;
alarm_viortc_vq = &viortc->vqs[VIORTC_ALARMQ];
alarm_vq = alarm_viortc_vq->vq;
@@ -1364,7 +1372,7 @@ static int viortc_restore(struct virtio_device *dev)
ret = viortc_populate_vq(viortc, alarm_viortc_vq,
VIORTC_ALARMQ_BUF_CAP, false);
if (ret)
- return ret;
+ goto err_remove;
notify = virtqueue_kick_prepare(alarm_vq);
}
@@ -1372,8 +1380,12 @@ static int viortc_restore(struct virtio_device *dev)
virtio_device_ready(dev);
if (notify && !virtqueue_notify(alarm_vq))
- ret = -EIO;
+ return -EIO;
+
+ return 0;
+err_remove:
+ __viortc_remove(viortc);
return ret;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: David Hildenbrand (Arm) @ 2026-04-25 5:17 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Pasha Tatashin, Lance Yang, peterz, dave.hansen,
dave.hansen, ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx,
mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett,
npache, ryan.roberts, dev.jain, baohua, shy828301, riel, jannh,
jgross, seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <CAO9r8zO4eSiAK9U-ijzWJMK80XsK+LmFxGAG+nTo+tmK6aLfYA@mail.gmail.com>
On 4/24/26 21:18, Yosry Ahmed wrote:
> On Fri, Apr 24, 2026 at 12:09 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 4/24/26 20:50, Yosry Ahmed wrote:
>>> On Fri, Apr 24, 2026 at 11:36 AM David Hildenbrand (Arm)
>>> <david@kernel.org> wrote:
>>>
>>> But I imagine it's useful for reviewers to see Sashiko's feedback as
>>> well (without having to go look on the website).
>>
>> I read a lot of them, yes. Maintainers know how to find it.
>>
>> I even think maintainers should briefly go over it before applying to spot if
>> anything in there is still left unanswered. But that doesn't need a mailing list
>> posting.
>>
>> I enjoy if contributors are aware of the reports and use that input in a
>> reasonable, like Zi just did [1]. And if they are unsure, they usually ask to
>> double-check.
>>
>> [1] https://lore.kernel.org/r/15191F7F-0D10-4907-B963-DA4EA0E36EB6@nvidia.com
>>
>>> It's possible that
>>> Sashiko is right but the author isn't convinced, so getting more eyes
>>> on the feedback would help.
>>
>> Forcing contributors to reply to everything. I don't like that, in particular
>> not as long as there is no way for contributors to run it early in private.
>>
>> In most cases, contributors just do the reasonable thing: incorporate the
>> feedback in a new version.
>
> The usefulness of the mailing list posting is that it makes it easier
> to respond and discuss the review. Yes, what Zi did is great, but it
> would be nice if contributors/reviewers didn't need to manually quote
> Sashiko.
I think the most important part is the contributor side. A private posting is
sufficient for that.
So if possible, I'd start with that and see how it goes.
>
> That being said, I understand the concerns and the pressure to respond
> to everything as you mention below. Maybe at some point this will
> become an easier decision to make as reviews become more refined.
There is another thing to consider here: impact on other reviewers, in
particular, new contributors, when they spot excessive review already posted to
the mailing list. And the first thing being them reading that.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: SeongJae Park @ 2026-04-25 1:19 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, David Hildenbrand (Arm), Pasha Tatashin,
Lance Yang, peterz, dave.hansen, dave.hansen, ypodemsk, hughd,
will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs,
ziy, baolin.wang, Liam.Howlett, npache, ryan.roberts, dev.jain,
baohua, shy828301, riel, jannh, jgross, seanjc, pbonzini,
boris.ostrovsky, virtualization, kvm, linux-arch, linux-mm,
linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <20260424073145.b990fe9b925da304508aad71@linux-foundation.org>
On Fri, 24 Apr 2026 07:31:45 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 24 Apr 2026 16:20:55 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
>
> > On 4/24/26 16:15, Andrew Morton wrote:
> > > On Fri, 24 Apr 2026 13:37:04 +0000 Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > >
> > >> On 04-24 06:30, Andrew Morton wrote:
> > >>>
> > >>>
> > >>> Sashiko questions:
> > >>> https://sashiko.dev/#/patchset/20260424062528.71951-1-lance.yang@linux.dev
> > >>>
> > >>> (I never know if my Sashiko emails are welcome/useful. Maybe Sashiko
> > >>> said the same stuff about v9 and it's all wrong. But better safe than
> > >>> sorry!)
> > >>
> > >> These emails are helpful; but, I do not believe you should have to
> > >> manually follow up with a link to every new patch series.
> > >>
> > >> Perhaps Sashiko could automatically send a summary email in response to
> > >> the cover letter, or provide a link once the reviews are complete. For
> > >> the kexec ML, we opted-in with Roman to receive automated emails from
> > >> sashiko.
> > >
> > > Yep. I'd be OK with an automatic reply-to-all. Maybe some won't like
> > > that.
> > >
> > > An alternative I've discussed with Roman is an automated
> > > reply-to-author with a cc to a dedicated list (we could use mm-commits
> > > for now).
> > >
> > > Preferences?
> >
> > Reply-to-author would likely be better as a first step.
>
> Why do you think so?
>
> Pasha, is it too early to determine how reply-to-all is working out for
> kexec?
DAMON is also opted in to Sashiko's email service. It is replied to only the
author and damon@lists.linux.dev. I understand this is the default form of
Sashiko's email service, and can flexibly tuned.
So I cannot say how reply-to-all will work for mm. But I can say the default
setup email service was a huge improvement for my life. I made tools for
making my Sashiko handling easier and was quite convinced with that. But the
Sashiko's email service made my life much better. Of course, it may differntly
applied to others. My personality is not necessarily same to others.
Thanks,
SJ
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: SeongJae Park @ 2026-04-25 1:12 UTC (permalink / raw)
To: Yosry Ahmed
Cc: SeongJae Park, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, peterz, dave.hansen, dave.hansen,
ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp,
x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett, npache,
ryan.roberts, dev.jain, baohua, shy828301, riel, jannh, jgross,
seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <CAO9r8zO4eSiAK9U-ijzWJMK80XsK+LmFxGAG+nTo+tmK6aLfYA@mail.gmail.com>
On Fri, 24 Apr 2026 12:18:49 -0700 Yosry Ahmed <yosry@kernel.org> wrote:
> On Fri, Apr 24, 2026 at 12:09 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
> >
> > On 4/24/26 20:50, Yosry Ahmed wrote:
> > > On Fri, Apr 24, 2026 at 11:36 AM David Hildenbrand (Arm)
> > > <david@kernel.org> wrote:
> > >>
> > >> On 4/24/26 16:31, Andrew Morton wrote:
> > >>>
> > >>>
> > >>> Why do you think so?
> > >>
> > >> The most important part for me is that authors are aware of the reports.
> > >>
> > >> Sending them as a mail forces people to publicly reply to the feedback, and at
> > >> this point in time, I am not convinced that that is the right approach.
> > >
> > > But I imagine it's useful for reviewers to see Sashiko's feedback as
> > > well (without having to go look on the website).
> >
> > I read a lot of them, yes. Maintainers know how to find it.
> >
> > I even think maintainers should briefly go over it before applying to spot if
> > anything in there is still left unanswered. But that doesn't need a mailing list
> > posting.
> >
> > I enjoy if contributors are aware of the reports and use that input in a
> > reasonable, like Zi just did [1]. And if they are unsure, they usually ask to
> > double-check.
> >
> > [1] https://lore.kernel.org/r/15191F7F-0D10-4907-B963-DA4EA0E36EB6@nvidia.com
> >
> > > It's possible that
> > > Sashiko is right but the author isn't convinced, so getting more eyes
> > > on the feedback would help.
> >
> > Forcing contributors to reply to everything. I don't like that, in particular
> > not as long as there is no way for contributors to run it early in private.
> >
> > In most cases, contributors just do the reasonable thing: incorporate the
> > feedback in a new version.
>
> The usefulness of the mailing list posting is that it makes it easier
> to respond and discuss the review. Yes, what Zi did is great, but it
> would be nice if contributors/reviewers didn't need to manually quote
> Sashiko.
I agree. I had to implement hkml-Sashiko integration [1] to avoid the manual
works. People could use such existign tools or develop their own. But I can
say Sashiko's direct mailing service has improved my dasy much more than the
hkml feature.
>
> That being said, I understand the concerns and the pressure to respond
> to everything as you mention below. Maybe at some point this will
> become an easier decision to make as reviews become more refined.
I agree here, too. Apparently [2] my tooling-motivated Sashiko reply
forwarding didn't convince all. My honest feeling was that it is not only
unconvincing but might making someone slightly annoyed.
I personally feel no problem at Sashiko review is publicly replied to my
patches, but I understand my personality is not necessarily same to others. If
some change can make someone happy while also making someone sad, I'm up to
reducing sadness.
[1] https://github.com/sjp38/hackermail/blob/master/USAGE.md#forwarding-sashikodev-statuscomments-to-mailing-list
[2] https://lore.kernel.org/20260331045245.67438-1-sj@kernel.org/
Thanks,
SJ
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: SeongJae Park @ 2026-04-25 0:58 UTC (permalink / raw)
To: Yosry Ahmed
Cc: SeongJae Park, Zi Yan, Peter Zijlstra, David Hildenbrand (Arm),
Andrew Morton, Pasha Tatashin, Lance Yang, dave.hansen,
dave.hansen, ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx,
mingo, bp, x86, hpa, arnd, ljs, baolin.wang, Liam.Howlett, npache,
ryan.roberts, dev.jain, baohua, shy828301, riel, jannh, jgross,
seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <CAO9r8zOTFUSXc_iZ3i9iL3v9Fw+SOFoROj0vcO_1GwBxO9CVqA@mail.gmail.com>
On Fri, 24 Apr 2026 12:15:30 -0700 Yosry Ahmed <yosry@kernel.org> wrote:
> On Fri, Apr 24, 2026 at 12:12 PM Zi Yan <ziy@nvidia.com> wrote:
> >
> > On 24 Apr 2026, at 15:01, Peter Zijlstra wrote:
> >
> > > On Fri, Apr 24, 2026 at 11:50:03AM -0700, Yosry Ahmed wrote:
> > >
> > >> But I imagine it's useful for reviewers to see Sashiko's feedback as
> > >> well (without having to go look on the website).
> > >
> > > That's why I have a script; if I press 'S' in mutt on an 0/n email, said
> > > script goes and does webrequest to sashiko and inserts the review
> > > comments into my local maildir as properly threaded replies to the
> > > series at hand.
> > >
> > > No looking at website needed.
> >
> > Do you mind sharing that script? It looks like a great work flow. Thanks.
>
> Yeah that sounds great :)
FWIW my workflow was also similar to PeterZ [1], except I use hkml's Sashiko
integration.
The hkml integration requires two key strokes to get the Sashiko review, so I
think Peter's script is superior. It provides a draft [2] for sharing full
Sashiko review that I can further writeup my comment and directly send, though.
It is helpful for asking the author their opinion about Sashiko's review, with
a fine pointer to the question.
So I initially started opening web browser to check Sashiko review. After that
I used hkml to read the review on terminal and copy-pasted the output to ask
question to authors with quote of Sashiko review. Finally I was able to just
forward Sashiko review together with my questions to authors. Each step of the
changes made my life much easier.
DAMON is opted in to the Sashiko's mail reply service from the beginning, and
recently Sashiko started the mail delivery. Now I don't need to use the hkml
integration, and I feel my life has been even much easier than before.
[1] https://github.com/sjp38/hackermail/blob/master/USAGE.md#sashikodev
[2] https://github.com/sjp38/hackermail/blob/master/USAGE.md#forwarding-sashikodev-statuscomments-to-mailing-list
Thanks,
SJ
^ permalink raw reply
* [syzbot ci] Re: vsock/virtio: fix memory leak in virtio_transport_recv_listen()
From: syzbot ci @ 2026-04-24 20:17 UTC (permalink / raw)
To: davem, edumazet, eperezma, horms, jasowang, kartikey406, kuba,
kvm, linux-kernel, mst, netdev, pabeni, sgarzare, stefanha,
syzbot, virtualization, xuanzhuo
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260424150310.57228-1-kartikey406@gmail.com>
syzbot ci has tested the following series
[v1] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
https://lore.kernel.org/all/20260424150310.57228-1-kartikey406@gmail.com
* [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
and found the following issue:
possible deadlock in virtio_transport_recv_listen
Full report is available here:
https://ci.syzbot.org/series/e5f3f5f1-8e83-492f-833b-dc526b61d0ef
***
possible deadlock in virtio_transport_recv_listen
tree: net-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
base: e728258debd553c95d2e70f9cd97c9fde27c7130
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/bcc67f3f-b441-4d11-8573-f26ca268da65/config
syz repro: https://ci.syzbot.org/findings/fce9fa9b-692a-420c-956f-12c7e6d75e2e/syz_repro
============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
kworker/1:5/6007 is trying to acquire lock:
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_listen+0x13a5/0x2230 net/vmw_vsock/virtio_transport_common.c:1593
but task is already holding lock:
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_pkt+0xfde/0x2bb0 net/vmw_vsock/virtio_transport_common.c:1671
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_VSOCK);
lock(sk_lock-AF_VSOCK);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/1:5/6007:
#0: ffff888112391940 ((wq_completion)vsock-loopback){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3277 [inline]
#0: ffff888112391940 ((wq_completion)vsock-loopback){+.+.}-{0:0}, at: process_scheduled_works+0xa35/0x1860 kernel/workqueue.c:3385
#1: ffffc900030dfc40 ((work_completion)(&vsock->pkt_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3278 [inline]
#1: ffffc900030dfc40 ((work_completion)(&vsock->pkt_work)){+.+.}-{0:0}, at: process_scheduled_works+0xa70/0x1860 kernel/workqueue.c:3385
#2: ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
#2: ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_pkt+0xfde/0x2bb0 net/vmw_vsock/virtio_transport_common.c:1671
stack backtrace:
CPU: 1 UID: 0 PID: 6007 Comm: kworker/1:5 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: vsock-loopback vsock_loopback_work
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_deadlock_bug+0x279/0x290 kernel/locking/lockdep.c:3041
check_deadlock kernel/locking/lockdep.c:3093 [inline]
validate_chain kernel/locking/lockdep.c:3895 [inline]
__lock_acquire+0x253f/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
lock_sock_nested+0x41/0x100 net/core/sock.c:3783
lock_sock include/net/sock.h:1713 [inline]
virtio_transport_recv_listen+0x13a5/0x2230 net/vmw_vsock/virtio_transport_common.c:1593
virtio_transport_recv_pkt+0x174b/0x2bb0 net/vmw_vsock/virtio_transport_common.c:1695
vsock_loopback_work+0x32c/0x3f0 net/vmw_vsock/vsock_loopback.c:142
process_one_work kernel/workqueue.c:3302 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3385
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3466
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Peter Zijlstra @ 2026-04-24 20:11 UTC (permalink / raw)
To: Roman Gushchin
Cc: Zi Yan, Yosry Ahmed, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, dave.hansen, dave.hansen, ypodemsk,
hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa,
arnd, ljs, baolin.wang, Liam.Howlett, npache, ryan.roberts,
dev.jain, baohua, shy828301, riel, jannh, jgross, seanjc,
pbonzini, boris.ostrovsky, virtualization, kvm, linux-arch,
linux-mm, linux-kernel, ioworker0
In-Reply-To: <7ia45x5gktx9.fsf@castle.c.googlers.com>
On Fri, Apr 24, 2026 at 08:03:14PM +0000, Roman Gushchin wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > On Fri, Apr 24, 2026 at 09:22:51PM +0200, Peter Zijlstra wrote:
> >
> >> mdir = mailbox.Maildir('~/Maildir/');
> >>
> >> for i, r in enumerate(reviews):
> >> inline = r.get('inline_review', '') or ''
> >> if not inline:
> >> continue
> >>
> >> author_name = r.get('author_name', 'Sashiko Reviewer')
> >> author_email = r.get('author_email', 'noreply@sashiko.dev')
> >>
> >> msgid = msgids[r['patch_id']]
> >> subject = subjects[r['patch_id']]
> >>
> >> # Create the Email object
> >> msg = EmailMessage()
> >> msg['Subject'] = f"Re: {subject}"
> >> msg['From'] = f"{author_name} <{author_email}>"
> >> msg['To'] = "peterz@infradead.org"
> >> msg['Date'] = formatdate(localtime=True)
> >>
> >> # The critical threading headers
> >> msg['Message-ID'] = f"<review-{i}-{msgid}>"
> >> msg['References'] = f"<{msgid}>"
> >> msg['In-Reply-To'] = f"<{msgid}>"
> >>
> >> msg.set_content(inline)
> >>
> >> mdir.add(msg)
> >>
> >> mdir.flush()
> >
> > So Ideally I would have 'Reply-to' header set to the original sender and
> > added 'Cc' like the original email. However, AFAICT the JSON does not
> > contain this information, and while I could use the mdir object to find
> > the original message in my Inbox, this is incredibly slow.
> >
> > I have a TODO to use python-notmuch to do this, but haven't gotten
> > around to doing this yet.
> >
> > With that 'fixed' I could actually reply to these messages and it would
> > all 'just' work. For now I copy/paste when needed.
>
> I can add an api to return a json with the review and all
> meta-information by the original msgid, will it be useful?
Oh yes, that would be more convenient. Thanks!
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Roman Gushchin @ 2026-04-24 20:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Zi Yan, Yosry Ahmed, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, dave.hansen, dave.hansen, ypodemsk,
hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa,
arnd, ljs, baolin.wang, Liam.Howlett, npache, ryan.roberts,
dev.jain, baohua, shy828301, riel, jannh, jgross, seanjc,
pbonzini, boris.ostrovsky, virtualization, kvm, linux-arch,
linux-mm, linux-kernel, ioworker0
In-Reply-To: <20260424193529.GA3853824@noisy.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> writes:
> On Fri, Apr 24, 2026 at 09:22:51PM +0200, Peter Zijlstra wrote:
>
>> mdir = mailbox.Maildir('~/Maildir/');
>>
>> for i, r in enumerate(reviews):
>> inline = r.get('inline_review', '') or ''
>> if not inline:
>> continue
>>
>> author_name = r.get('author_name', 'Sashiko Reviewer')
>> author_email = r.get('author_email', 'noreply@sashiko.dev')
>>
>> msgid = msgids[r['patch_id']]
>> subject = subjects[r['patch_id']]
>>
>> # Create the Email object
>> msg = EmailMessage()
>> msg['Subject'] = f"Re: {subject}"
>> msg['From'] = f"{author_name} <{author_email}>"
>> msg['To'] = "peterz@infradead.org"
>> msg['Date'] = formatdate(localtime=True)
>>
>> # The critical threading headers
>> msg['Message-ID'] = f"<review-{i}-{msgid}>"
>> msg['References'] = f"<{msgid}>"
>> msg['In-Reply-To'] = f"<{msgid}>"
>>
>> msg.set_content(inline)
>>
>> mdir.add(msg)
>>
>> mdir.flush()
>
> So Ideally I would have 'Reply-to' header set to the original sender and
> added 'Cc' like the original email. However, AFAICT the JSON does not
> contain this information, and while I could use the mdir object to find
> the original message in my Inbox, this is incredibly slow.
>
> I have a TODO to use python-notmuch to do this, but haven't gotten
> around to doing this yet.
>
> With that 'fixed' I could actually reply to these messages and it would
> all 'just' work. For now I copy/paste when needed.
I can add an api to return a json with the review and all
meta-information by the original msgid, will it be useful?
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Peter Zijlstra @ 2026-04-24 19:35 UTC (permalink / raw)
To: Zi Yan
Cc: Yosry Ahmed, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, dave.hansen, dave.hansen, ypodemsk,
hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa,
arnd, ljs, baolin.wang, Liam.Howlett, npache, ryan.roberts,
dev.jain, baohua, shy828301, riel, jannh, jgross, seanjc,
pbonzini, boris.ostrovsky, virtualization, kvm, linux-arch,
linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <20260424192250.GC3783056@noisy.programming.kicks-ass.net>
On Fri, Apr 24, 2026 at 09:22:51PM +0200, Peter Zijlstra wrote:
> mdir = mailbox.Maildir('~/Maildir/');
>
> for i, r in enumerate(reviews):
> inline = r.get('inline_review', '') or ''
> if not inline:
> continue
>
> author_name = r.get('author_name', 'Sashiko Reviewer')
> author_email = r.get('author_email', 'noreply@sashiko.dev')
>
> msgid = msgids[r['patch_id']]
> subject = subjects[r['patch_id']]
>
> # Create the Email object
> msg = EmailMessage()
> msg['Subject'] = f"Re: {subject}"
> msg['From'] = f"{author_name} <{author_email}>"
> msg['To'] = "peterz@infradead.org"
> msg['Date'] = formatdate(localtime=True)
>
> # The critical threading headers
> msg['Message-ID'] = f"<review-{i}-{msgid}>"
> msg['References'] = f"<{msgid}>"
> msg['In-Reply-To'] = f"<{msgid}>"
>
> msg.set_content(inline)
>
> mdir.add(msg)
>
> mdir.flush()
So Ideally I would have 'Reply-to' header set to the original sender and
added 'Cc' like the original email. However, AFAICT the JSON does not
contain this information, and while I could use the mdir object to find
the original message in my Inbox, this is incredibly slow.
I have a TODO to use python-notmuch to do this, but haven't gotten
around to doing this yet.
With that 'fixed' I could actually reply to these messages and it would
all 'just' work. For now I copy/paste when needed.
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: David Hildenbrand (Arm) @ 2026-04-24 19:24 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Yosry Ahmed, Andrew Morton, Pasha Tatashin, Lance Yang,
dave.hansen, dave.hansen, ypodemsk, hughd, will, aneesh.kumar,
npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang,
Liam.Howlett, npache, ryan.roberts, dev.jain, baohua, shy828301,
riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0, roman.gushchin
In-Reply-To: <20260424191703.GB3783056@noisy.programming.kicks-ass.net>
On 4/24/26 21:17, Peter Zijlstra wrote:
> On Fri, Apr 24, 2026 at 09:09:21PM +0200, David Hildenbrand (Arm) wrote:
>
>> Forcing contributors to reply to everything. I don't like that, in particular
>> not as long as there is no way for contributors to run it early in private.
>>
>> In most cases, contributors just do the reasonable thing: incorporate the
>> feedback in a new version.
>
> Yes, so I understand that you can run it locally, but then you get to
> pay for the tokens (and sashiko burns tokens like dry grass). I also
> understand why Google/LF doesn't open this up, its a money pit no doubt.
Indeed.
>
> OTOH, I see this causing more reposts of series than we would have had
> previously -- and we all love more versions of series.
Fortunately, reposts are easy to review, at least for me, when tags are properly
incorporated and the version diff properly describes the changes.
>
> I'm not sure I see a solution, other than to read less email -- its not
> like I can even begin to read all email I get anyway.
Sad but true.
I consider the last AI review before something gets merged the most important one.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Peter Zijlstra @ 2026-04-24 19:22 UTC (permalink / raw)
To: Zi Yan
Cc: Yosry Ahmed, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, dave.hansen, dave.hansen, ypodemsk,
hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa,
arnd, ljs, baolin.wang, Liam.Howlett, npache, ryan.roberts,
dev.jain, baohua, shy828301, riel, jannh, jgross, seanjc,
pbonzini, boris.ostrovsky, virtualization, kvm, linux-arch,
linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <E375C69C-557E-44EB-9B3C-618C9F7BA9D8@nvidia.com>
On Fri, Apr 24, 2026 at 03:12:34PM -0400, Zi Yan wrote:
> On 24 Apr 2026, at 15:01, Peter Zijlstra wrote:
>
> > On Fri, Apr 24, 2026 at 11:50:03AM -0700, Yosry Ahmed wrote:
> >
> >> But I imagine it's useful for reviewers to see Sashiko's feedback as
> >> well (without having to go look on the website).
> >
> > That's why I have a script; if I press 'S' in mutt on an 0/n email, said
> > script goes and does webrequest to sashiko and inserts the review
> > comments into my local maildir as properly threaded replies to the
> > series at hand.
> >
> > No looking at website needed.
>
> Do you mind sharing that script? It looks like a great work flow. Thanks.
Sure, it is in a 'works-for-me' state and probably should get a once
over before you run it locally to make sure it fits your environment (at
the very least you should probably change my email address :-)
This is cobbled toghether from a script I got from Thomas and staring at
the JSON with generous hints from Gemini (because I can't write Python
at all).
.muttrc has:
macro index S "<pipe-entry>grep -i \"\^Message-ID:\" | cut -d: -f2- | tr -d \" <>\" | ~/bin/sashiko.py<enter>"
sashiko.py:
---
#!/usr/bin/env python3
import sys
import mailbox
import requests
from argparse import ArgumentParser
from email.message import EmailMessage
from email.utils import formatdate
from datetime import datetime
def getsash(url, msgid):
surl = f'{url.rstrip("/")}/api/patch'
try:
session = requests.Session()
session.headers.update({'User-Agent': 'sash2txt_0.2'})
resp = session.get(surl, params={'id': msgid}, timeout=30)
if resp.status_code == 404:
print(f"Error: Patch ID {msgid} not found (404).", file=sys.stderr)
return
resp.raise_for_status()
data = resp.json()
except requests.RequestException as ex:
print(f"Request failed: {ex}", file=sys.stderr)
return
patches = data.get('patches', [])
if not patches:
print(f"No patches found for (msgid).", file=sys.stderr)
return
msgids = {}
subjects = {}
for p in patches:
msgids[p['id']] = p['message_id']
subjects[p['id']] = p['subject']
reviews = data.get('reviews', [])
if not reviews:
print(f"No reviews found for {msgid}.", file=sys.stderr)
return
mdir = mailbox.Maildir('~/Maildir/');
for i, r in enumerate(reviews):
inline = r.get('inline_review', '') or ''
if not inline:
continue
author_name = r.get('author_name', 'Sashiko Reviewer')
author_email = r.get('author_email', 'noreply@sashiko.dev')
msgid = msgids[r['patch_id']]
subject = subjects[r['patch_id']]
# Create the Email object
msg = EmailMessage()
msg['Subject'] = f"Re: {subject}"
msg['From'] = f"{author_name} <{author_email}>"
msg['To'] = "peterz@infradead.org"
msg['Date'] = formatdate(localtime=True)
# The critical threading headers
msg['Message-ID'] = f"<review-{i}-{msgid}>"
msg['References'] = f"<{msgid}>"
msg['In-Reply-To'] = f"<{msgid}>"
msg.set_content(inline)
mdir.add(msg)
mdir.flush()
if __name__ == '__main__':
url = 'https://sashiko.dev/'
# Check if there's data in stdin (piped input)
if not sys.stdin.isatty():
for line in sys.stdin:
msgid = line.strip()
if msgid:
getsash(url, msgid)
else:
# Fallback to arguments if no pipe is detected
parser = ArgumentParser(description='Sashiko retriever to mbox')
parser.add_argument('msgid', nargs='?', help='Message id of the patch series')
args = parser.parse_args()
if args.msgid:
getsash(url, args.msgid)
else:
print("Usage: echo <msgid> | ./sashiko.py OR ./sashiko.py <msgid>", file=sys.stderr)
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Yosry Ahmed @ 2026-04-24 19:18 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Andrew Morton, Pasha Tatashin, Lance Yang, peterz, dave.hansen,
dave.hansen, ypodemsk, hughd, will, aneesh.kumar, npiggin, tglx,
mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang, Liam.Howlett,
npache, ryan.roberts, dev.jain, baohua, shy828301, riel, jannh,
jgross, seanjc, pbonzini, boris.ostrovsky, virtualization, kvm,
linux-arch, linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <4e7699eb-e101-4a25-b585-79a777eb7cc2@kernel.org>
On Fri, Apr 24, 2026 at 12:09 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 4/24/26 20:50, Yosry Ahmed wrote:
> > On Fri, Apr 24, 2026 at 11:36 AM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 4/24/26 16:31, Andrew Morton wrote:
> >>>
> >>>
> >>> Why do you think so?
> >>
> >> The most important part for me is that authors are aware of the reports.
> >>
> >> Sending them as a mail forces people to publicly reply to the feedback, and at
> >> this point in time, I am not convinced that that is the right approach.
> >
> > But I imagine it's useful for reviewers to see Sashiko's feedback as
> > well (without having to go look on the website).
>
> I read a lot of them, yes. Maintainers know how to find it.
>
> I even think maintainers should briefly go over it before applying to spot if
> anything in there is still left unanswered. But that doesn't need a mailing list
> posting.
>
> I enjoy if contributors are aware of the reports and use that input in a
> reasonable, like Zi just did [1]. And if they are unsure, they usually ask to
> double-check.
>
> [1] https://lore.kernel.org/r/15191F7F-0D10-4907-B963-DA4EA0E36EB6@nvidia.com
>
> > It's possible that
> > Sashiko is right but the author isn't convinced, so getting more eyes
> > on the feedback would help.
>
> Forcing contributors to reply to everything. I don't like that, in particular
> not as long as there is no way for contributors to run it early in private.
>
> In most cases, contributors just do the reasonable thing: incorporate the
> feedback in a new version.
The usefulness of the mailing list posting is that it makes it easier
to respond and discuss the review. Yes, what Zi did is great, but it
would be nice if contributors/reviewers didn't need to manually quote
Sashiko.
That being said, I understand the concerns and the pressure to respond
to everything as you mention below. Maybe at some point this will
become an easier decision to make as reviews become more refined.
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Peter Zijlstra @ 2026-04-24 19:17 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Yosry Ahmed, Andrew Morton, Pasha Tatashin, Lance Yang,
dave.hansen, dave.hansen, ypodemsk, hughd, will, aneesh.kumar,
npiggin, tglx, mingo, bp, x86, hpa, arnd, ljs, ziy, baolin.wang,
Liam.Howlett, npache, ryan.roberts, dev.jain, baohua, shy828301,
riel, jannh, jgross, seanjc, pbonzini, boris.ostrovsky,
virtualization, kvm, linux-arch, linux-mm, linux-kernel,
ioworker0, roman.gushchin
In-Reply-To: <4e7699eb-e101-4a25-b585-79a777eb7cc2@kernel.org>
On Fri, Apr 24, 2026 at 09:09:21PM +0200, David Hildenbrand (Arm) wrote:
> Forcing contributors to reply to everything. I don't like that, in particular
> not as long as there is no way for contributors to run it early in private.
>
> In most cases, contributors just do the reasonable thing: incorporate the
> feedback in a new version.
Yes, so I understand that you can run it locally, but then you get to
pay for the tokens (and sashiko burns tokens like dry grass). I also
understand why Google/LF doesn't open this up, its a money pit no doubt.
OTOH, I see this causing more reposts of series than we would have had
previously -- and we all love more versions of series.
I'm not sure I see a solution, other than to read less email -- its not
like I can even begin to read all email I get anyway.
^ permalink raw reply
* Re: [PATCH 7.2 v10 0/2] skip redundant sync IPIs when TLB flush sent them
From: Yosry Ahmed @ 2026-04-24 19:15 UTC (permalink / raw)
To: Zi Yan
Cc: Peter Zijlstra, David Hildenbrand (Arm), Andrew Morton,
Pasha Tatashin, Lance Yang, dave.hansen, dave.hansen, ypodemsk,
hughd, will, aneesh.kumar, npiggin, tglx, mingo, bp, x86, hpa,
arnd, ljs, baolin.wang, Liam.Howlett, npache, ryan.roberts,
dev.jain, baohua, shy828301, riel, jannh, jgross, seanjc,
pbonzini, boris.ostrovsky, virtualization, kvm, linux-arch,
linux-mm, linux-kernel, ioworker0, roman.gushchin
In-Reply-To: <E375C69C-557E-44EB-9B3C-618C9F7BA9D8@nvidia.com>
On Fri, Apr 24, 2026 at 12:12 PM Zi Yan <ziy@nvidia.com> wrote:
>
> On 24 Apr 2026, at 15:01, Peter Zijlstra wrote:
>
> > On Fri, Apr 24, 2026 at 11:50:03AM -0700, Yosry Ahmed wrote:
> >
> >> But I imagine it's useful for reviewers to see Sashiko's feedback as
> >> well (without having to go look on the website).
> >
> > That's why I have a script; if I press 'S' in mutt on an 0/n email, said
> > script goes and does webrequest to sashiko and inserts the review
> > comments into my local maildir as properly threaded replies to the
> > series at hand.
> >
> > No looking at website needed.
>
> Do you mind sharing that script? It looks like a great work flow. Thanks.
Yeah that sounds great :)
^ 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