* Re: [PATCH 0/2] Fix lock errors in VDUSE suspend feature
From: Michael S. Tsirkin @ 2026-06-11 14:49 UTC (permalink / raw)
To: Eugenio Pérez
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang, Xuan Zhuo,
Laurent Vivier, virtualization, linux-kernel, Cindy Lu,
Yongji Xie
In-Reply-To: <20260611133806.198402-1-eperezma@redhat.com>
On Thu, Jun 11, 2026 at 03:38:04PM +0200, Eugenio Pérez wrote:
> Fix wrong ordering at taking semaphore after spinlock and convert the spinlock
> take and release into guards, so they are not lost after a return.
>
> This series goes on top of https://lore.kernel.org/lkml/20260610083452.477759-1-eperezma@redhat.com/
You mean
20260610-vduse_vq_kick-fix-guard-usage-v1-1-0ce02c08006e@kernel.org
actually
> ---
> It would be great if these can be squashed.
>
> Eugenio Pérez (2):
> vduse: fix not releasing taken semaphore in vduse_dev_queue_irq_work
> vduse: not take the device semaphore while holding vq spinlock
>
> drivers/vdpa/vdpa_user/vduse_dev.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH 0/2] Fix lock errors in VDUSE suspend feature
From: Michael S. Tsirkin @ 2026-06-11 14:46 UTC (permalink / raw)
To: Eugenio Pérez
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang, Xuan Zhuo,
Laurent Vivier, virtualization, linux-kernel, Cindy Lu,
Yongji Xie
In-Reply-To: <20260611133806.198402-1-eperezma@redhat.com>
On Thu, Jun 11, 2026 at 03:38:04PM +0200, Eugenio Pérez wrote:
> Fix wrong ordering at taking semaphore after spinlock and convert the spinlock
> take and release into guards, so they are not lost after a return.
>
> This series goes on top of https://lore.kernel.org/lkml/20260610083452.477759-1-eperezma@redhat.com/
does not apply there.
> ---
> It would be great if these can be squashed.
>
> Eugenio Pérez (2):
> vduse: fix not releasing taken semaphore in vduse_dev_queue_irq_work
> vduse: not take the device semaphore while holding vq spinlock
>
> drivers/vdpa/vdpa_user/vduse_dev.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH 0/2] Fix lock errors in VDUSE suspend feature
From: Michael S. Tsirkin @ 2026-06-11 14:14 UTC (permalink / raw)
To: Eugenio Pérez
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang, Xuan Zhuo,
Laurent Vivier, virtualization, linux-kernel, Cindy Lu,
Yongji Xie
In-Reply-To: <20260611133806.198402-1-eperezma@redhat.com>
On Thu, Jun 11, 2026 at 03:38:04PM +0200, Eugenio Pérez wrote:
> Fix wrong ordering at taking semaphore after spinlock and convert the spinlock
> take and release into guards, so they are not lost after a return.
>
> This series goes on top of https://lore.kernel.org/lkml/20260610083452.477759-1-eperezma@redhat.com/
> ---
> It would be great if these can be squashed.
if you want that then just send v4.
>
> Eugenio Pérez (2):
> vduse: fix not releasing taken semaphore in vduse_dev_queue_irq_work
> vduse: not take the device semaphore while holding vq spinlock
>
> drivers/vdpa/vdpa_user/vduse_dev.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH 0/2] Fix lock errors in VDUSE suspend feature
From: Michael S. Tsirkin @ 2026-06-11 14:12 UTC (permalink / raw)
To: Eugenio Pérez
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang, Xuan Zhuo,
Laurent Vivier, virtualization, linux-kernel, Cindy Lu,
Yongji Xie
In-Reply-To: <20260611133806.198402-1-eperezma@redhat.com>
On Thu, Jun 11, 2026 at 03:38:04PM +0200, Eugenio Pérez wrote:
> Fix wrong ordering at taking semaphore after spinlock and convert the spinlock
> take and release into guards, so they are not lost after a return.
>
> This series goes on top of https://lore.kernel.org/lkml/20260610083452.477759-1-eperezma@redhat.com/
And vduse: Fix error around jumping over a __cleanup() variable
does it obliviate that?
> ---
> It would be great if these can be squashed.
>
> Eugenio Pérez (2):
> vduse: fix not releasing taken semaphore in vduse_dev_queue_irq_work
> vduse: not take the device semaphore while holding vq spinlock
>
> drivers/vdpa/vdpa_user/vduse_dev.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH v6 5/7] locking: Add contended_release tracepoint to qspinlock
From: Peter Zijlstra @ 2026-06-11 13:44 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Thomas Bogendoerfer, Juergen Gross, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Thomas Gleixner,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-mips,
virtualization, linux-arch, linux-mm, linux-trace-kernel,
kernel-team, Paul E. McKenney
In-Reply-To: <aiphFXe_TPNPxZ_n@shell.ilvokhin.com>
On Thu, Jun 11, 2026 at 07:17:41AM +0000, Dmitry Ilvokhin wrote:
> On Wed, Jun 03, 2026 at 02:08:11PM +0200, Peter Zijlstra wrote:
> > Also, I think someone should go do some performance runs with
> > ARCH_INLINE_SPIN_* set for x86 just like for s390.
>
> As promised, I set ARCH_INLINE_SPIN_UNLOCK{,_BH,_IRQ,_IRQRESTORE} for
> x86 and measured the effect on a few real workloads.
>
> Short version: inlining of _raw_spin_unlock() adds measurable kernel
> i-cache pressure on every workload I tried, and on a
> kernel-i-cache-bound one (nginx connection churn) it costs ~1.27%
> throughput. I did not find a workload where it helps.
Thanks for checking!
^ permalink raw reply
* [PATCH 2/2] vduse: not take the device semaphore while holding vq spinlock
From: Eugenio Pérez @ 2026-06-11 13:38 UTC (permalink / raw)
To: Michael S . Tsirkin
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang,
Eugenio Pérez, Xuan Zhuo, Laurent Vivier, virtualization,
linux-kernel, Cindy Lu, Yongji Xie
In-Reply-To: <20260611133806.198402-1-eperezma@redhat.com>
It's an invalid lock pattern, so take them reversely.
This also makes the lock ordering coherent with vduse_dev_reset.
Fixes: e4a249d15eb2 ("vduse: Fix error around jumping over a __cleanup() variable")
Fixes: 6c141c034c1b ("vduse: Add suspend")
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
index 86bd3116eda7..2c1cafea6536 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -561,14 +561,14 @@ static int vduse_vdpa_set_vq_address(struct vdpa_device *vdpa, u16 idx,
static void vduse_vq_kick(struct vduse_virtqueue *vq)
{
- guard(spinlock)(&vq->kick_lock);
- if (!vq->ready)
- return;
-
guard(rwsem_read)(&vq->dev->rwsem);
if (vq->dev->suspended)
return;
+ guard(spinlock)(&vq->kick_lock);
+ if (!vq->ready)
+ return;
+
if (vq->kickfd)
eventfd_signal(vq->kickfd);
else
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] vduse: fix not releasing taken semaphore in vduse_dev_queue_irq_work
From: Eugenio Pérez @ 2026-06-11 13:38 UTC (permalink / raw)
To: Michael S . Tsirkin
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang,
Eugenio Pérez, Xuan Zhuo, Laurent Vivier, virtualization,
linux-kernel, Cindy Lu, Yongji Xie
In-Reply-To: <20260611133806.198402-1-eperezma@redhat.com>
If dev->suspended the function returns not relasing the semaphore, so
the only solution to be able to use the device is to reset again from
userspace. Convert the semaphore functions to the equivalent guard() to
avoid it.
Fixes: 6c141c034c1b ("vduse: Add suspend")
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
index 0500da043761..86bd3116eda7 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -1281,21 +1281,16 @@ static int vduse_dev_queue_irq_work(struct vduse_dev *dev,
{
int ret = -EINVAL;
- down_read(&dev->rwsem);
- if (dev->suspended)
+ guard(rwsem_read)(&dev->rwsem);
+ if (dev->suspended || !(dev->status & VIRTIO_CONFIG_S_DRIVER_OK))
return ret;
- if (!(dev->status & VIRTIO_CONFIG_S_DRIVER_OK))
- goto unlock;
-
ret = 0;
if (irq_effective_cpu == IRQ_UNBOUND)
queue_work(vduse_irq_wq, irq_work);
else
queue_work_on(irq_effective_cpu,
vduse_irq_bound_wq, irq_work);
-unlock:
- up_read(&dev->rwsem);
return ret;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] Fix lock errors in VDUSE suspend feature
From: Eugenio Pérez @ 2026-06-11 13:38 UTC (permalink / raw)
To: Michael S . Tsirkin
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang,
Eugenio Pérez, Xuan Zhuo, Laurent Vivier, virtualization,
linux-kernel, Cindy Lu, Yongji Xie
Fix wrong ordering at taking semaphore after spinlock and convert the spinlock
take and release into guards, so they are not lost after a return.
This series goes on top of https://lore.kernel.org/lkml/20260610083452.477759-1-eperezma@redhat.com/
---
It would be great if these can be squashed.
Eugenio Pérez (2):
vduse: fix not releasing taken semaphore in vduse_dev_queue_irq_work
vduse: not take the device semaphore while holding vq spinlock
drivers/vdpa/vdpa_user/vduse_dev.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH splitout] mm: memory-failure: serialize TestSetPageHWPoison with zone->lock
From: David Hildenbrand (Arm) @ 2026-06-11 13:20 UTC (permalink / raw)
To: Miaohe Lin, Michael S. Tsirkin
Cc: Zi Yan, Andrew Morton, linux-kernel, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Muchun Song, Oscar Salvador, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain,
Barry Song, Lance Yang, Hugh Dickins, Matthew Brost, Joshua Hahn,
Rakie Kim, Byungchul Park, Gregory Price, Ying Huang,
Alistair Popple, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Axel Rasmussen, Yuanchu Xie, Wei Xu,
Chris Li, Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He,
virtualization, linux-mm, Andrea Arcangeli, Naoya Horiguchi
In-Reply-To: <1b5676ab-0dc5-ef33-9d79-a2bd6090a62d@huawei.com>
On 6/11/26 09:36, Miaohe Lin wrote:
> On 2026/6/11 13:43, Michael S. Tsirkin wrote:
>> On Thu, Jun 11, 2026 at 11:35:36AM +0800, Miaohe Lin wrote:
>>>
>>> Do you mean repeating SetPageHWPoison on every branch?
>>
>> Right.
>>
>>> Is it possible
>>> to make __free_pages_prepare changes page->flags atomically or this race
>>> is specified to memory_failure?
>>>
>>> Thanks.
>>> .
>>
>>
>> Adding an atomic op on every fast path page allocation is, I am
>> guessing, going to slow down Linux measureably.
>>
>> Doing it for the benefit of memory_failure, which is the slowest of
>> slow paths, seems unpalatable, to me.
>
> Agree, it's not worth to do so.
>
>>
>> Neither am I sure it's the only racy place -
>> grep for __SetPage and __ClearPage - all these have the same issue, I
>> suspect.
>>
>> At the same time, I'm not an mm maintainer. If you disagree, try to
>> upstream a change converting all non atomics in mm to atomics, and see
>> what others say.
>
> Since memory_failure might be the only place, this change would be unacceptable.
> We should come up with a better solution. Maybe we can try repeating SetPageHWPoison
> and ClearPageHWPoison at a first attempt though it looks somewhat weird to me and makes
> code more complicated.
And I am fairly sure we could still have some remaining races ... it's shaky.
Hm ...
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v3 2/4] scsi: host: allocate struct Scsi_Host on the NUMA node of the host adapter
From: Stefan Hajnoczi @ 2026-06-10 15:37 UTC (permalink / raw)
To: Sumit Saxena, Michael S. Tsirkin
Cc: Martin K . Petersen, Jens Axboe, James E . J . Bottomley,
linux-scsi, linux-block, Adam Radford, Khalid Aziz,
Adaptec OEM Raid Solutions, Matthew Wilcox, Hannes Reinecke,
Juergen E . Fischer, Russell King, linux-arm-kernel, Finn Thain,
Michael Schmitz, Anil Gurumurthy, Sudarsana Kalluru,
Oliver Neukum, Ali Akcaagac, Jamie Lenehan, Ram Vegesna,
target-devel, Bradley Grove, Satish Kharat, Sesidhar Baddela,
Karan Tilak Kumar, Yihang Li, Don Brace, storagedev,
HighPoint Linux Team, Tyrel Datwyler, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, linuxppc-dev,
Brian King, Lee Duncan, Chris Leech, Mike Christie, open-iscsi,
Justin Tee, Paul Ely, Kashyap Desai, Shivasharan S,
Chandrakanth Patil, megaraidlinux.pdl, Sathya Prakash Veerichetty,
Sreekanth Reddy, mpi3mr-linuxdrv.pdl, Suganath Prabu Subramani,
Ranjan Kumar, MPT-FusionLinux.pdl, Daniel Palmer, GOTO Masanori,
Jack Wang, Geoff Levand, Michael Reed, Nilesh Javali,
GR-QLogic-Storage-Upstream, Narsimhulu Musini, K . Y . Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, linux-hyperv,
Michael S . Tsirkin, Jason Wang, Paolo Bonzini, Eugenio Perez,
virtualization, Vishal Bhakta, bcm-kernel-feedback-list,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
xen-devel, John Garry
In-Reply-To: <20260609121806.2121755-3-sumit.saxena@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
On Tue, Jun 09, 2026 at 05:48:01PM +0530, Sumit Saxena wrote:
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 5fdaa71f0652..88375574cb18 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -929,7 +929,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
> num_targets = virtscsi_config_get(vdev, max_target) + 1;
>
> shost = scsi_host_alloc(&virtscsi_host_template,
> - struct_size(vscsi, req_vqs, num_queues));
> + struct_size(vscsi, req_vqs, num_queues), NULL);
A virtio_device has a parent (this is the virtio transport, like
virtio_pci) and that may have NUMA node.
drivers/virtio/virtio.c:register_virtio_device() could call
set_dev_node(dev, dev_to_node(dev->parent)) to propagate the NUMA node
to the virtio_device if it is not already automatically propagated.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH splitout] mm: memory-failure: serialize TestSetPageHWPoison with zone->lock
From: David Hildenbrand (Arm) @ 2026-06-11 11:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Andrew Morton, linux-kernel, Miaohe Lin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Muchun Song, Oscar Salvador, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Baolin Wang, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, Hugh Dickins, Matthew Brost,
Joshua Hahn, Rakie Kim, Byungchul Park, Gregory Price, Ying Huang,
Alistair Popple, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Axel Rasmussen, Yuanchu Xie, Wei Xu,
Chris Li, Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He,
virtualization, linux-mm, Andrea Arcangeli, Naoya Horiguchi
In-Reply-To: <20260611023208-mutt-send-email-mst@kernel.org>
On 6/11/26 08:33, Michael S. Tsirkin wrote:
> On Tue, Jun 09, 2026 at 08:38:09PM +0200, David Hildenbrand (Arm) wrote:
>> On 6/9/26 20:10, Andrew Morton wrote:
>>>
>>>
>>> Sashiko is saying this doesn't do anything "Because
>>> __free_pages_prepare() executes entirely locklessly". Did it goof?
>>>
>>> https://sashiko.dev/#/patchset/df06b66fe4ff8e925ee0714955abc2183a727b90.1780998980.git.mst@redhat.com
>>
>> Battle of the bots: it's right.
>
> Ugh it's bot against human - I remembered we have zone lock
> normally in alloc and thought it helps and didn't double check we don't
> have it here . The bot wins (
Heh, I was primarily looking whether taking the lock would be harmful, not if it
would be useful. :)
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v5 01/15] drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips
From: Thomas Zimmermann @ 2026-06-11 11:09 UTC (permalink / raw)
To: Javier Martinez Canillas, mripard, maarten.lankhorst, airlied,
airlied, simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, harry.wentland, sunpeng.li,
siqueira, alexander.deucher, rodrigo.vivi, joonas.lahtinen,
tursulin, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Zack Rusin, stable
In-Reply-To: <87mrx15om7.fsf@ocarina.mail-host-address-is-not-set>
Hi
Am 11.06.26 um 12:59 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <tzimmermann@suse.de> writes:
>
>> Hi Javier
>>
>> Am 11.06.26 um 12:10 schrieb Javier Martinez Canillas:
>>> Thomas Zimmermann <tzimmermann@suse.de> writes:
>>>
>>> Hello Thomas,
>>>
>>>> The mode-setting pipeline can disabled damage clippings for a commit
>>>> by setting ignore_damage_clips in struct drm_plane_state. The commit
>>>> will then do a full display update.
>>>>
>>>> Test the flag in DCN code and do a full update in DCN code if it has
>>>> been set.
>>>>
>>>> Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers
>>>> to ignore damage clips") introduced ignore_damage_clips to selectively
>>>> ignore damage clipping in certain framebuffer changes. This driver does
>>>> not do that, but DRM's damage iterator will soon rely on the flag.
>>>> Therefore supporting it here as well make sense for consistency.
>>>>
>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
>>> I don't think that a Fixes tag is correct here? Your patch series
>>> is changing the 'struct drm_plane_state.ignore_damage_clips' and
>>> the changes make sense, but definitely isn't a fix in my opinion.
>> But shouldn't we have added this test in amdgpu and the other drivers as
>> part of commit 35ed38d58257 ? Sure, these drivers don't use
>> ignore_damage_clips, but it's still an inconsistency wrt damage
> I don't think so, since the original scope of ignore_damage_clips was for DRM
> driver of virtual devices (namely virtio-gpu and vmwgfx). These do per-buffer
> uploads instead of per-plane uploads, and so there was a need to force a full
> plane update if the framebuffer attached to the plane was changed.
>
> Your series are now extending the scope of ignore_damage_clips to be used by
> core helpers and force a full plane update when doing a modeset. This makes
> sense to me but it wasn't the original intention of the propery and that is
> why I don't think that should be considered a fix.
>
> The only patch that IMO is really a fix for commit 35ed38d58257 is patch #6.
> Because is true that the plane state ignore_damage_clips was carried over
> when the state was duplicated.
Ok, I'll drop the Fixes tags then.
Best regards
Thomas
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v5 01/15] drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips
From: Javier Martinez Canillas @ 2026-06-11 10:59 UTC (permalink / raw)
To: Thomas Zimmermann, mripard, maarten.lankhorst, airlied, airlied,
simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, harry.wentland, sunpeng.li,
siqueira, alexander.deucher, rodrigo.vivi, joonas.lahtinen,
tursulin, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Zack Rusin, stable
In-Reply-To: <45aec54a-ec80-48ed-9bcc-84e7bccc11eb@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Hi Javier
>
> Am 11.06.26 um 12:10 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann <tzimmermann@suse.de> writes:
>>
>> Hello Thomas,
>>
>>> The mode-setting pipeline can disabled damage clippings for a commit
>>> by setting ignore_damage_clips in struct drm_plane_state. The commit
>>> will then do a full display update.
>>>
>>> Test the flag in DCN code and do a full update in DCN code if it has
>>> been set.
>>>
>>> Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers
>>> to ignore damage clips") introduced ignore_damage_clips to selectively
>>> ignore damage clipping in certain framebuffer changes. This driver does
>>> not do that, but DRM's damage iterator will soon rely on the flag.
>>> Therefore supporting it here as well make sense for consistency.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
>> I don't think that a Fixes tag is correct here? Your patch series
>> is changing the 'struct drm_plane_state.ignore_damage_clips' and
>> the changes make sense, but definitely isn't a fix in my opinion.
>
> But shouldn't we have added this test in amdgpu and the other drivers as
> part of commit 35ed38d58257 ? Sure, these drivers don't use
> ignore_damage_clips, but it's still an inconsistency wrt damage
I don't think so, since the original scope of ignore_damage_clips was for DRM
driver of virtual devices (namely virtio-gpu and vmwgfx). These do per-buffer
uploads instead of per-plane uploads, and so there was a need to force a full
plane update if the framebuffer attached to the plane was changed.
Your series are now extending the scope of ignore_damage_clips to be used by
core helpers and force a full plane update when doing a modeset. This makes
sense to me but it wasn't the original intention of the propery and that is
why I don't think that should be considered a fix.
The only patch that IMO is really a fix for commit 35ed38d58257 is patch #6.
Because is true that the plane state ignore_damage_clips was carried over
when the state was duplicated.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH v3 3/4] block: drop shared-tag fairness throttling
From: Sumit Saxena @ 2026-06-11 10:43 UTC (permalink / raw)
To: Keith Busch
Cc: Christoph Hellwig, Martin K . Petersen, Jens Axboe,
James E . J . Bottomley, linux-scsi, linux-block, Adam Radford,
Khalid Aziz, Adaptec OEM Raid Solutions, Matthew Wilcox,
Hannes Reinecke, Juergen E . Fischer, Russell King,
linux-arm-kernel, Finn Thain, Michael Schmitz, Anil Gurumurthy,
Sudarsana Kalluru, Oliver Neukum, Ali Akcaagac, Jamie Lenehan,
Ram Vegesna, target-devel, Bradley Grove, Satish Kharat,
Sesidhar Baddela, Karan Tilak Kumar, Yihang Li, Don Brace,
storagedev, HighPoint Linux Team, Tyrel Datwyler,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, linuxppc-dev, Brian King, Lee Duncan,
Chris Leech, Mike Christie, open-iscsi, Justin Tee, Paul Ely,
Kashyap Desai, Shivasharan S, Chandrakanth Patil,
megaraidlinux.pdl, Sathya Prakash Veerichetty, Sreekanth Reddy,
mpi3mr-linuxdrv.pdl, Suganath Prabu Subramani, Ranjan Kumar,
MPT-FusionLinux.pdl, Daniel Palmer, GOTO Masanori, YOKOTA Hiroshi,
Jack Wang, Geoff Levand, Michael Reed, Nilesh Javali,
GR-QLogic-Storage-Upstream, Narsimhulu Musini, K . Y . Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, linux-hyperv,
Michael S . Tsirkin, Jason Wang, Paolo Bonzini, Stefan Hajnoczi,
Eugenio Perez, virtualization, Vishal Bhakta,
bcm-kernel-feedback-list, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, xen-devel, Bart Van Assche
In-Reply-To: <aimSb9I0Vl-68hy9@kbusch-mbp>
[-- Attachment #1.1: Type: text/plain, Size: 1232 bytes --]
On Wed, Jun 10, 2026 at 10:06 PM Keith Busch <kbusch@kernel.org> wrote:
>
> On Wed, Jun 10, 2026 at 09:16:11PM +0530, Sumit Saxena wrote:
> > The motivation for this change stems from performance issue we
> > encountered due to false sharing of the 'nr_active_requests_shared_tags'
> > counter
> > on certain CPU architectures. I initially submitted a patch to move that
> > counter to
> > its own cache line to avoid conflicts with 'nr_requests' and other hot
> > fields
> > (see:
> >
https://patchwork.kernel.org/project/linux-scsi/patch/20260402074637.92417-3-sumit.saxena@broadcom.com/
> > ).
> >
> > During the review, Bart shared his work, which eliminates the
> > counter entirely by removing the fairness throttling. My testing
confirmed
> > that
> > this approach resolved the performance issues and improved IOPS.
> > This patch is part of a larger set, and I have reported the cumulative
> > performance
> > improvements in the cover letter.
>
> So the problem is just the atomic operation accounting overhead? I
> previously thought the device just really needed to consume all the tags
> to hit performance.
That's correct, it's the atomic operation accounting overhead.
Thanks,
Sumit
[-- Attachment #1.2: Type: text/html, Size: 1660 bytes --]
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Michael S. Tsirkin @ 2026-06-11 10:42 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <aip9nja-Oz2RxkWi@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 05:19:26PM +0800, Herbert Xu wrote:
> On Thu, Jun 11, 2026 at 05:10:32AM -0400, Michael S. Tsirkin wrote:
> >
> > data_avail is under hypervisor control
> >
> > avail = min_t(unsigned int, vi->data_avail, sizeof(vi->data));
> > if (vi->data_idx >= avail) {
> > vi->data_idx = 0;
> >
> > and maybe this can speculate past the if?
> >
> > I agree, this is all speculation )
>
> Either it is vulnerable to Spectre, or it isn't. Adding nospec
> markers when you're not sure is cargo cult programming.
AKA defence is depth programming)
Alright we can drop this. No biggie.
--
MST
^ permalink raw reply
* Re: [PATCH v5 01/15] drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips
From: Thomas Zimmermann @ 2026-06-11 10:41 UTC (permalink / raw)
To: Javier Martinez Canillas, mripard, maarten.lankhorst, airlied,
airlied, simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, harry.wentland, sunpeng.li,
siqueira, alexander.deucher, rodrigo.vivi, joonas.lahtinen,
tursulin, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Zack Rusin, stable
In-Reply-To: <87y0gl5qw8.fsf@ocarina.mail-host-address-is-not-set>
Hi Javier
Am 11.06.26 um 12:10 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <tzimmermann@suse.de> writes:
>
> Hello Thomas,
>
>> The mode-setting pipeline can disabled damage clippings for a commit
>> by setting ignore_damage_clips in struct drm_plane_state. The commit
>> will then do a full display update.
>>
>> Test the flag in DCN code and do a full update in DCN code if it has
>> been set.
>>
>> Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers
>> to ignore damage clips") introduced ignore_damage_clips to selectively
>> ignore damage clipping in certain framebuffer changes. This driver does
>> not do that, but DRM's damage iterator will soon rely on the flag.
>> Therefore supporting it here as well make sense for consistency.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
> I don't think that a Fixes tag is correct here? Your patch series
> is changing the 'struct drm_plane_state.ignore_damage_clips' and
> the changes make sense, but definitely isn't a fix in my opinion.
But shouldn't we have added this test in amdgpu and the other drivers as
part of commit 35ed38d58257 ? Sure, these drivers don't use
ignore_damage_clips, but it's still an inconsistency wrt damage
handlers. Hence the Fixes tag. Another problem is that the drivers never
did the test for changes to the plane-state src coordinate that the
damage iterator does. But that is only fixed later in the series.
>
> Having said that, the change look good to me.
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thanks for reviewing.
Best regards
Thomas
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v3] vduse: Add suspend
From: Michael S. Tsirkin @ 2026-06-11 10:38 UTC (permalink / raw)
To: Eugenio Perez Martin
Cc: Dan Carpenter, oe-kbuild, lkp, oe-kbuild-all, virtualization,
Jason Wang, Cindy Lu, Xuan Zhuo, Stefano Garzarella, linux-kernel,
Laurent Vivier, Yongji Xie, Maxime Coquelin
In-Reply-To: <CAJaqyWdQ7_1zYcfNVF_vQrrLHf_TRAbqS0X1kMQm7QMZ4UY+kA@mail.gmail.com>
On Thu, Jun 11, 2026 at 11:30:23AM +0200, Eugenio Perez Martin wrote:
> On Thu, Jun 11, 2026 at 11:20 AM Dan Carpenter <error27@gmail.com> wrote:
> >
> > On Thu, Jun 11, 2026 at 05:03:24AM -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jun 11, 2026 at 10:18:51AM +0300, Dan Carpenter wrote:
> > > > Hi Eugenio,
> > > >
> > > > kernel test robot noticed the following build warnings:
> > > >
> > > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > > >
> > > > url: https://github.com/intel-lab-lkp/linux/commits/Eugenio-P-rez/vduse-Add-suspend/20260610-164534
> > > > base: next-20260609
> > > > patch link: https://lore.kernel.org/r/20260610083452.477759-1-eperezma%40redhat.com
> > > > patch subject: [PATCH v3] vduse: Add suspend
> > > > config: arm64-randconfig-r072-20260610 (https://download.01.org/0day-ci/archive/20260611/202606111115.tKKe1qCE-lkp@intel.com/config)
> > > > compiler: aarch64-linux-gcc (GCC) 8.5.0
> > > > smatch: v0.5.0-9185-gbcc58b9c
> > > >
> > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > the same patch/commit), kindly add following tags
> > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > | Reported-by: Dan Carpenter <error27@gmail.com>
> > > > | Closes: https://lore.kernel.org/r/202606111115.tKKe1qCE-lkp@intel.com/
> > > >
> > > > smatch warnings:
> > > > drivers/vdpa/vdpa_user/vduse_dev.c:577 vduse_vq_kick() warn: inconsistent returns '&vq->kick_lock'.
> > > > drivers/vdpa/vdpa_user/vduse_dev.c:1302 vduse_dev_queue_irq_work() warn: inconsistent returns '&dev->rwsem'.
> > > >
> > > > vim +577 drivers/vdpa/vdpa_user/vduse_dev.c
> > > >
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 562 static void vduse_vq_kick(struct vduse_virtqueue *vq)
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 563 {
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 564 spin_lock(&vq->kick_lock);
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 565 if (!vq->ready)
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 566 goto unlock;
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 567
> > > > 9c4307e82fa1dc Eugenio Pérez 2026-06-10 568 guard(rwsem_read)(&vq->dev->rwsem);
> > > > 9c4307e82fa1dc Eugenio Pérez 2026-06-10 569 if (vq->dev->suspended)
> > > > 9c4307e82fa1dc Eugenio Pérez 2026-06-10 570 return;
> > > >
> > > > unlock before returning?
> > > >
> > > > 9c4307e82fa1dc Eugenio Pérez 2026-06-10 571
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 572 if (vq->kickfd)
> > > > 3652117f854819 Christian Brauner 2023-11-22 573 eventfd_signal(vq->kickfd);
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 574 else
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 575 vq->kicked = true;
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 576 unlock:
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 @577 spin_unlock(&vq->kick_lock);
> > > > c8a6153b6c59d9 Xie Yongji 2021-08-31 578 }
> > >
> > >
> > > I think this is fixed by:
> > >
> > > commit e4a249d15eb2d4b28213bebb1eefaf2e6d99de0b (HEAD -> vhost, linux-next-vhost/linux-next, kernel.org/vhost, kernel.org/test)
> > > Author: Nathan Chancellor <nathan@kernel.org>
> > > Date: Wed Jun 10 12:16:49 2026 -0700
> > >
> > > vduse: Fix error around jumping over a __cleanup() variable
> > >
> > > right?
> >
> > These things haven't hit linux-next yet. I found the email.
> > https://lore.kernel.org/all/20260610-vduse_vq_kick-fix-guard-usage-v1-1-0ce02c08006e@kernel.org/
> >
> > That only fixes the bug in vduse_vq_kick(), not the bug in
> > vduse_dev_queue_irq_work(). I don't see a fix for that
> > yet on lore but I may have missed it.
> >
>
> No, I can test & send a fast patch for that.
>
> Thanks!
Alright.
--
MST
^ permalink raw reply
* Re: [PATCH v5 04/15] drm/vmwgfx: Handle struct drm_plane_state.ignore_damage_clips
From: Javier Martinez Canillas @ 2026-06-11 10:12 UTC (permalink / raw)
To: Thomas Zimmermann, mripard, maarten.lankhorst, airlied, airlied,
simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, harry.wentland, sunpeng.li,
siqueira, alexander.deucher, rodrigo.vivi, joonas.lahtinen,
tursulin, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Thomas Zimmermann, Zack Rusin, stable
In-Reply-To: <20260610152505.260172-5-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The mode-setting pipeline can disabled damage clippings for a commit
> by setting ignore_damage_clips in struct drm_plane_state. The commit
> will then do a full display update.
>
> Test the flag in the primary ldu plane's atomic_update and do a full
> update if it has been set.
>
> Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers
> to ignore damage clips") introduced ignore_damage_clips to selectively
> ignore damage clipping in certain framebuffer changes. Vmwgfx does not
> do that, but DRM's damage iterator will soon rely on the flag. Therefore
> supporting it here as well make sense for consistency.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH v5 03/15] drm/vboxvideo: Handle struct drm_plane_state.ignore_damage_clips
From: Javier Martinez Canillas @ 2026-06-11 10:12 UTC (permalink / raw)
To: Thomas Zimmermann, mripard, maarten.lankhorst, airlied, airlied,
simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, harry.wentland, sunpeng.li,
siqueira, alexander.deucher, rodrigo.vivi, joonas.lahtinen,
tursulin, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Thomas Zimmermann, Zack Rusin, stable
In-Reply-To: <20260610152505.260172-4-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The mode-setting pipeline can disabled damage clippings for a commit
> by setting ignore_damage_clips in struct drm_plane_state. The commit
> will then do a full display update.
>
> Test the flag in the primary plane's atomic_update and do a full update
> if it has been set.
>
> Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers
> to ignore damage clips") introduced ignore_damage_clips to selectively
> ignore damage clipping in certain framebuffer changes. Vboxvideo does not
> do that, but DRM's damage iterator will soon rely on the flag. Therefore
> supporting it here as well make sense for consistency.
>
> While at it, also replace uint32_t with the preferred u32.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
And for this one as well.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH v5 02/15] drm/i915/display: Handle struct drm_plane_state.ignore_damage_clips
From: Javier Martinez Canillas @ 2026-06-11 10:11 UTC (permalink / raw)
To: Thomas Zimmermann, mripard, maarten.lankhorst, airlied, airlied,
simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, harry.wentland, sunpeng.li,
siqueira, alexander.deucher, rodrigo.vivi, joonas.lahtinen,
tursulin, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Thomas Zimmermann, stable, Zack Rusin
In-Reply-To: <20260610152505.260172-3-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The mode-setting pipeline can disabled damage clippings for a commit
> by setting ignore_damage_clips in struct drm_plane_state. The commit
> will then do a full display update. Commit 35ed38d58257 ("drm: Allow
> drivers to indicate the damage helpers to ignore damage clips") introduced
> ignore_damage_clips to selectively ignore damage clipping in certain
> framebuffer changes.
>
> The i915 driver does not modify the flag, but DRM's damage iterator
> will soon rely on it. Calling drm_atomic_helper_check_plane_damage()
> right before drm_atomic_helper_damage_merged() guarantees that it
> has the correct state. The i915 driver does not do this elsewhere
> so far.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
Same comment here than for patch #1. I don't think this is a fix.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH v5 01/15] drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips
From: Javier Martinez Canillas @ 2026-06-11 10:10 UTC (permalink / raw)
To: Thomas Zimmermann, mripard, maarten.lankhorst, airlied, airlied,
simona, admin, gargaditya08, paul, jani.nikula, mhklkml,
zack.rusin, bcm-kernel-feedback-list, harry.wentland, sunpeng.li,
siqueira, alexander.deucher, rodrigo.vivi, joonas.lahtinen,
tursulin, dmitry.osipenko, gurchetansingh, olvaffe
Cc: dri-devel, linux-hyperv, intel-gfx, intel-xe, linux-mips,
virtualization, amd-gfx, Thomas Zimmermann, Zack Rusin, stable
In-Reply-To: <20260610152505.260172-2-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello Thomas,
> The mode-setting pipeline can disabled damage clippings for a commit
> by setting ignore_damage_clips in struct drm_plane_state. The commit
> will then do a full display update.
>
> Test the flag in DCN code and do a full update in DCN code if it has
> been set.
>
> Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers
> to ignore damage clips") introduced ignore_damage_clips to selectively
> ignore damage clipping in certain framebuffer changes. This driver does
> not do that, but DRM's damage iterator will soon rely on the flag.
> Therefore supporting it here as well make sense for consistency.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips")
I don't think that a Fixes tag is correct here? Your patch series
is changing the 'struct drm_plane_state.ignore_damage_clips' and
the changes make sense, but definitely isn't a fix in my opinion.
Having said that, the change look good to me.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH] vduse: Fix error around jumping over a __cleanup() variable
From: David Laight @ 2026-06-11 10:03 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
virtualization, linux-kernel, llvm
In-Reply-To: <20260610-vduse_vq_kick-fix-guard-usage-v1-1-0ce02c08006e@kernel.org>
On Wed, 10 Jun 2026 12:16:49 -0700
Nathan Chancellor <nathan@kernel.org> wrote:
> When building with clang, there is an error in vduse_vq_kick() from
> attempting to jump over a variable declared with the cleanup attribute
> using goto:
.
> Jumping over a variable declared with the cleanup attribute does not
> prevent the cleanup function from running, it would just result in the
> variable being passed uninitialized to the cleanup function .clang
> errors instead of generating the invalid code, unlike GCC.
Does the same apply to variables allocated inside switch statements?
I'm sure I've seen one that wasn't inside an extra block.
David
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()
From: Stefano Garzarella @ 2026-06-11 9:59 UTC (permalink / raw)
To: Raf Dickson
Cc: netdev, virtualization, pabeni, stefanha, bryan-bt.tan,
vishnu.dasa, bcm-kernel-feedback-list, bobbyeshleman
In-Reply-To: <20260611095509.19125-1-rafdog35@gmail.com>
On Thu, Jun 11, 2026 at 09:55:09AM +0000, Raf Dickson wrote:
>On Thu, Jun 11, 2026 at 09:42:12AM +0200, Stefano Garzarella wrote:
>> Okay, but VMCI still need to call vsock_add_pending() and
>> sk_acceptq_added() in vmci_transport_recv_listen(), no?
>
>Yes correct, vsock_add_pending() and sk_acceptq_added() stay in
>recv_listen(). vsock_pending_to_accept() only replaces the
>vsock_remove_pending() + vsock_enqueue_accept() calls in
>recv_connecting_server() once the handshake completes.
>
>So the v3 series will be 4 patches:
> 1/4: introduce vsock_pending_to_accept()
> 2/4: fold sk_acceptq_added() into vsock_add_pending()
> 3/4: fold sk_acceptq_added() into vsock_enqueue_accept() (virtio/hyperv)
> 4/4: fold sk_acceptq_removed() into vsock_remove_pending()
Okay, LGTM!
Stefano
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] vsock: fold sk_acceptq_added() into vsock_enqueue_accept()
From: Raf Dickson @ 2026-06-11 9:55 UTC (permalink / raw)
To: sgarzare
Cc: netdev, virtualization, pabeni, stefanha, bryan-bt.tan,
vishnu.dasa, bcm-kernel-feedback-list, bobbyeshleman
In-Reply-To: <aiqCQCdPHw7Ja3tM@sgarzare-redhat>
On Thu, Jun 11, 2026 at 09:42:12AM +0200, Stefano Garzarella wrote:
> Okay, but VMCI still need to call vsock_add_pending() and
> sk_acceptq_added() in vmci_transport_recv_listen(), no?
Yes correct, vsock_add_pending() and sk_acceptq_added() stay in
recv_listen(). vsock_pending_to_accept() only replaces the
vsock_remove_pending() + vsock_enqueue_accept() calls in
recv_connecting_server() once the handshake completes.
So the v3 series will be 4 patches:
1/4: introduce vsock_pending_to_accept()
2/4: fold sk_acceptq_added() into vsock_add_pending()
3/4: fold sk_acceptq_added() into vsock_enqueue_accept() (virtio/hyperv)
4/4: fold sk_acceptq_removed() into vsock_remove_pending()
Raf
^ permalink raw reply
* Re: [PATCH net] virtio-net: fix len check in receive_big()
From: David Laight @ 2026-06-11 9:48 UTC (permalink / raw)
To: Xiang Mei
Cc: mst, jasowang, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, virtualization, linux-kernel,
minhquangbui99, bestswngs
In-Reply-To: <20260610221606.1091465-1-xmei5@asu.edu>
On Wed, 10 Jun 2026 15:16:06 -0700
Xiang Mei <xmei5@asu.edu> wrote:
> receive_big() bounds the device-announced length by
> (big_packets_num_skbfrags + 1) * PAGE_SIZE. That is still too loose:
> add_recvbuf_big() sets sg[1] to start at offset
> sizeof(struct padded_vnet_hdr) into the first page, so the chain
> actually carries hdr_len + (PAGE_SIZE - sizeof(padded_vnet_hdr)) +
> big_packets_num_skbfrags * PAGE_SIZE bytes -- 20 bytes less than the
> check allows for the common hdr_len == 12 case.
>
> A malicious virtio backend can announce a len in that gap. page_to_skb()
> then walks one frag past the page chain, storing a NULL page->private
> into skb_shinfo()->frags[MAX_SKB_FRAGS], which is both an out-of-bounds
> write past the static frag array and a NULL frag handed up the rx path.
>
> Bound len by the size add_recvbuf_big() actually advertised.
>
> Fixes: 0c716703965f ("virtio-net: fix received length check in big packets")
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> ---
> drivers/net/virtio_net.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index f4adcfee7a80..afe73eda1491 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1999,15 +1999,17 @@ static struct sk_buff *receive_big(struct net_device *dev,
> struct virtnet_rq_stats *stats)
> {
> struct page *page = buf;
> + unsigned long max_len;
> struct sk_buff *skb;
>
> /* Make sure that len does not exceed the size allocated in
> * add_recvbuf_big.
> */
> - if (unlikely(len > (vi->big_packets_num_skbfrags + 1) * PAGE_SIZE)) {
> + max_len = vi->hdr_len + (PAGE_SIZE - sizeof(struct padded_vnet_hdr)) +
> + vi->big_packets_num_skbfrags * PAGE_SIZE;
That looks like a constant (for the vi).
Probably worth saving rather than recalculating all the time.
-- David
> + if (unlikely(len > max_len)) {
> pr_debug("%s: rx error: len %u exceeds allocated size %lu\n",
> - dev->name, len,
> - (vi->big_packets_num_skbfrags + 1) * PAGE_SIZE);
> + dev->name, len, max_len);
> goto err;
> }
>
^ 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