* 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 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 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] 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 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 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 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 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 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 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
* [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
* [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 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
* 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
* 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 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: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: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:53 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.
ok i figured out the confusion. 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 net-next v2 1/2] virtio_net: xsk: fix race in rx wake up
From: Bui Quang Minh @ 2026-06-11 16:24 UTC (permalink / raw)
To: menglong8.dong, xuanzhuo, eperezma
Cc: mst, jasowang, andrew+netdev, davem, edumazet, kuba, pabeni,
kerneljasonxing, netdev, virtualization, linux-kernel
In-Reply-To: <20260611025644.2431148-2-dongml2@chinatelecom.cn>
On 6/11/26 09:56, menglong8.dong@gmail.com wrote:
> From: Menglong Dong <dongml2@chinatelecom.cn>
>
> During packet receiving in virtio-net, the rq can be empty, which means
> "rq->vq->num_free == virtqueue_get_vring_size(rq->vq)", in
> virtnet_add_recvbuf_xsk(), if we are using xsk. Meanwhile, the fill ring
> can be empty too, which means we can't allocate anything from
> xsk_buff_alloc_batch(). Then, we will set the XDP_RING_NEED_WAKEUP flag.
>
> However, if the user clean all the data in rx ring and fill the
> "fill ring" and check the XDP_RING_NEED_WAKEUP flag after
> xsk_buff_alloc_batch() and before xsk_set_rx_need_wakeup(), then the rx
> napi will never be scheduled: the rx ring is empty, which means we will
> never receive a packet to trigger the further recv fill. The rx ring is
> empty now, so the user will not check the flag too.
>
> Fix this by set the XDP_RING_NEED_WAKEUP flag before
> xsk_buff_alloc_batch() if both rq->vq and fill ring are empty.
>
> Meanwhile, set the XDP_RING_NEED_WAKEUP flag if we have any free entry in
> rq->vq.
>
> Fixes: e3f8800aa243 ("virtio-net: xsk: Support wakeup on RX side")
> Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> ---
> drivers/net/virtio_net.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index f4adcfee7a80..4b5b3fa62008 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1323,16 +1323,27 @@ static int virtnet_add_recvbuf_xsk(struct virtnet_info *vi, struct receive_queue
> struct xsk_buff_pool *pool, gfp_t gfp)
> {
> struct xdp_buff **xsk_buffs;
> + bool need_wakeup;
> dma_addr_t addr;
> int err = 0;
> u32 len, i;
> int num;
>
> + need_wakeup = xsk_uses_need_wakeup(pool);
> xsk_buffs = rq->xsk_buffs;
>
> + /* If both rq->vq and fill ring are empty, and then the user submit
> + * all the chunks to the fill ring and check the wake up flag
> + * after xsk_buff_alloc_batch() and before xsk_set_rx_need_wakeup(),
> + * we will lose the chance to wake up the rx napi, so we have to
> + * set the need_wakeup flag here.
> + */
> + if (need_wakeup && virtqueue_get_vring_size(rq->vq) == rq->vq->num_free)
> + xsk_set_rx_need_wakeup(pool);
I think when polling the receive queue, the userspace program needs to
check the XDP_RING_NEED_WAKEUP flag if it does not see any packets. The
flag check is quite lightweight in my opinion. Here are some examples I find
-
https://github.com/xdp-project/xdp-tools/blob/e9469501622aa22a7e452a671000bec8685edcde/lib/util/xdpsock.c#L1206
-
https://github.com/xdp-project/bpf-examples/blob/43e565901c4287efa863edca7f0e6cd6e35ed896/AF_XDP-forwarding/xsk_fwd.c#L540
Furthermore, the XDP_RING_NEED_WAKEUP flag related functions does not
provide any memory orderings. So even with your patch, I'm worried that
this case is possible
kernel userspace
xsk_buff_alloc_batch -> failed
submit fill
ring
flag !=
XDP_RING_NEED_WAKEUP
// reordering due to lack of memory orderings
xsk_set_rx_need_wakeup
I'm not expert here, so correct me if I'm wrong. I think the wake up
flag is designed with no orderings so we cannot rely on it to reason and
skip further checks.
> +
> num = xsk_buff_alloc_batch(pool, xsk_buffs, rq->vq->num_free);
> if (!num) {
> - if (xsk_uses_need_wakeup(pool)) {
> + if (need_wakeup) {
> xsk_set_rx_need_wakeup(pool);
> /* Return 0 instead of -ENOMEM so that NAPI is
> * descheduled.
> @@ -1341,8 +1352,6 @@ static int virtnet_add_recvbuf_xsk(struct virtnet_info *vi, struct receive_queue
> }
>
> return -ENOMEM;
> - } else {
> - xsk_clear_rx_need_wakeup(pool);
> }
>
> len = xsk_pool_get_rx_frame_size(pool) + vi->hdr_len;
> @@ -1363,6 +1372,16 @@ static int virtnet_add_recvbuf_xsk(struct virtnet_info *vi, struct receive_queue
> goto err;
> }
>
> + if (need_wakeup) {
> + if (rq->vq->num_free)
> + /* We have free buffers, so we'd better wake up the
> + * rx napi as soon as possible.
> + */
> + xsk_set_rx_need_wakeup(pool);
> + else
> + xsk_clear_rx_need_wakeup(pool);
> + }
> +
Why do we need to set XDP_RING_NEED_WAKEUP even when
xsk_buff_alloc_batch succeeds?
> return num;
>
> err:
Thanks,
Quang Minh.
^ permalink raw reply
* Re: [PATCH 0/2] Fix lock errors in VDUSE suspend feature
From: Eugenio Perez Martin @ 2026-06-11 16:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Maxime Coquelin, Stefano Garzarella, Jason Wang, Xuan Zhuo,
Laurent Vivier, virtualization, linux-kernel, Cindy Lu,
Yongji Xie
In-Reply-To: <20260611105251-mutt-send-email-mst@kernel.org>
On Thu, Jun 11, 2026 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> 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.
>
> ok i figured out the confusion. squashed
>
Yes, you're right; this is on top of Nathan's. Thanks for both merging
and figuring it out!
^ permalink raw reply
* [PATCH v2 net] virtio_net: do not allow tunnel csum offload for non GSO packets
From: Paolo Abeni @ 2026-06-11 16:36 UTC (permalink / raw)
To: netdev
Cc: Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
virtualization, Gabriel Goller, Fiona Ebner
Fiona reports broken connectivity for virtio net setup using UDP tunnel
inside the guest and NIC with not UDP tunnel TSO support in the host.
Currently the virtio_net driver exposes csum offload for UDP-tunneled,
TCP non GSO packets. Such packet reach the host as CSUM_PARTIAL ones
with the 'encapsulation' flag cleared, as the virtio specification do
not support this specific kind of offload.
HW NICs with UDP tunnel TSO support - and those drivers directly
accessing skb->csum_start/csum_offset - are still capable of computing
the needed csum correctly, but otherwise the packets reach the wire with
bad csum on both the inner and outer transport header.
Address the issue explicitly disabling csum offload for UDP tunneled,
non GSO packets via the ndo_features_check op.
Fixes: 56a06bd40fab ("virtio_net: enable gso over UDP tunnel support.")
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Closes: https://bugzilla.proxmox.com/show_bug.cgi?id=7627
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Gabriel Goller <g.goller@proxmox.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
v1 -> v2:
- deal with to-be-segmented skbs, too.
---
drivers/net/virtio_net.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f4adcfee7a80..7d2eeb9b1226 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -6222,6 +6222,19 @@ static void virtnet_free_irq_moder(struct virtnet_info *vi)
rtnl_unlock();
}
+static netdev_features_t virtnet_features_check(struct sk_buff *skb,
+ struct net_device *dev,
+ netdev_features_t features)
+{
+ /* Inner csum offload is only available for GSO packets. */
+ if (skb->encapsulation &&
+ (!skb_is_gso(skb) || netif_needs_gso(skb, features)))
+ return features & ~NETIF_F_CSUM_MASK;
+
+ /* Passthru. */
+ return features;
+}
+
static const struct net_device_ops virtnet_netdev = {
.ndo_open = virtnet_open,
.ndo_stop = virtnet_close,
@@ -6235,7 +6248,7 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_bpf = virtnet_xdp,
.ndo_xdp_xmit = virtnet_xdp_xmit,
.ndo_xsk_wakeup = virtnet_xsk_wakeup,
- .ndo_features_check = passthru_features_check,
+ .ndo_features_check = virtnet_features_check,
.ndo_get_phys_port_name = virtnet_get_phys_port_name,
.ndo_set_features = virtnet_set_features,
.ndo_tx_timeout = virtnet_tx_timeout,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 0/3] virtiofs: hiprio FORGET robustness and no-reply request completion
From: Stefan Hajnoczi @ 2026-06-11 17:25 UTC (permalink / raw)
To: German Maglione
Cc: Li Wang, Vivek Goyal, Stefan Hajnoczi, Eugenio Pérez,
virtualization, linux-fsdevel, linux-kernel, Miklos Szeredi
In-Reply-To: <CAJfpegs8v6a9D1zWsNY7pX_Zx1wgjGvoEFS6hkk+qE2iDQptZw@mail.gmail.com>
On Thu, Jun 11, 2026 at 5:34 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Thu, 2 Apr 2026 at 12:45, Li Wang <liwang@kylinos.cn> wrote:
> >
> > This series fixes virtiofs completion for FUSE requests that do not use a
> > reply descriptor, tightens hiprio FORGET handling when virtqueue submission
> > fails transiently, and prevents the hiprio worker from stalling when one
> > FORGET must be dropped after an unrecoverable error.
>
> Can someone from the virtiofs team please review this?
German: Are you available to review this? I am can review patches as a
fallback but would prefer for you to handle them most of the time
since I haven't been actively involved in virtiofs for some time.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH net-next 0/3] xsk: support tx napi busy_poll
From: Maciej Fijalkowski @ 2026-06-11 18:40 UTC (permalink / raw)
To: menglong8.dong
Cc: jasowang, mst, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
kuba, pabeni, magnus.karlsson, sdf, horms, ast, daniel, hawk,
john.fastabend, bjorn, kerneljasonxing, netdev, virtualization,
linux-kernel, bpf
In-Reply-To: <20260611071242.2485058-1-dongml2@chinatelecom.cn>
On Thu, Jun 11, 2026 at 03:12:39PM +0800, menglong8.dong@gmail.com wrote:
> From: Menglong Dong <dongml2@chinatelecom.cn>
>
> For now, we use sk_busy_loop() in __xsk_sendmsg() to send the data in tx
> ring. The sk_busy_loop() will poll on the target NAPI. However, for the
> nic driver that support the tx napi, such as virtio-net, it can't schedule
> the tx NAPI, but only the rx NAPI. If we enable the busy_poll for xsk and
> use virtio-net, we can't send data, as the rx NAPI in virtio-net doesn't
> handle the packet sending.
Am I reading this right that you decided to break busy-poll support for
zero-copy drivers that happen to handle transmit side from Rx NAPI context
in favor of supporting virtio-net?
>
> Fix this by introduce the sk_tx_busy_loop(), which will poll on the tx
> NAPI if available. To get the tx NAPI from the napi_id, we add the
> "tx_napi" field to napi_struct, which is ugly :/
>
> Another choice is to call virtnet_xsk_xmit() in virtnet_poll() too. But
> this a little contradict the design of tx NAPI.
>
> Menglong Dong (3):
> net: busy-poll: introduce sk_tx_busy_loop()
> virtio_net: initialize napi.tx_napi in virtnet_alloc_queues()
> xsk: replace sk_busy_loop with sk_tx_busy_loop in __xsk_sendmsg()
>
> drivers/net/virtio_net.c | 1 +
> include/linux/netdevice.h | 1 +
> include/net/busy_poll.h | 41 ++++++++++++++++++++++++++++++++++++---
> net/core/dev.c | 23 +++++-----------------
> net/xdp/xsk.c | 2 +-
> 5 files changed, 46 insertions(+), 22 deletions(-)
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH net-next] vsock/vmci: use sk_acceptq_is_full() helper
From: Jakub Kicinski @ 2026-06-11 20:26 UTC (permalink / raw)
To: Luigi Leonardi
Cc: Raf Dickson, netdev, virtualization, pabeni, sgarzare, stefanha,
bryan-bt.tan, vishnu.dasa, bcm-kernel-feedback-list
In-Reply-To: <aippcmlliXpO0BXM@leonardi-redhat>
On Thu, 11 Jun 2026 09:58:22 +0200 Luigi Leonardi wrote:
> note: according to patchwork [1] you forgot to CC some maintainers,
> please be more careful next time :)
Please focus your reviews on the code not patchwork checks.
^ 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