* Re: [PATCH v3 2/4] scsi: host: allocate struct Scsi_Host on the NUMA node of the host adapter
From: Hannes Reinecke @ 2026-06-10 5:59 UTC (permalink / raw)
To: Sumit Saxena, Martin K . Petersen, Jens Axboe
Cc: James E . J . Bottomley, linux-scsi, linux-block, Adam Radford,
Khalid Aziz, Adaptec OEM Raid Solutions, Matthew Wilcox,
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, John Garry
In-Reply-To: <20260609121806.2121755-3-sumit.saxena@broadcom.com>
On 6/9/26 14:18, Sumit Saxena wrote:
> scsi_host_alloc() used kzalloc(), which always picks an arbitrary node.
> Extend the function to accept a 'struct device *dev' parameter and use
> kzalloc_node() with dev_to_node(dev) so the Scsi_Host struct lands on
> the same NUMA node as the HBA, mirroring the treatment already applied
> to struct scsi_device, struct scsi_target, and shost_data.
>
> When dev is NULL (legacy ISA/platform drivers without a dma_dev) the
> allocation falls back to NUMA_NO_NODE, preserving existing behaviour.
>
> Update all in-tree callers:
> - PCI-based HBA drivers pass &pdev->dev (or the equivalent struct
> member such as &phba->pcidev->dev, &h->pdev->dev, &ha->pdev->dev)
> so their host struct is placed on the adapter's node.
> - Non-PCI drivers (ISA, Amiga, ARM PCMCIA, virtio, Hyper-V, PS3, …)
> pass NULL.
> - libfc's libfc_host_alloc() inline helper passes NULL; FC drivers
> that want NUMA awareness can open-code the call with their pdev.
>
> Suggested-by: John Garry <john.g.garry@oracle.com>
> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> ---
> drivers/scsi/3w-9xxx.c | 2 +-
> drivers/scsi/3w-sas.c | 2 +-
> drivers/scsi/3w-xxxx.c | 2 +-
> drivers/scsi/53c700.c | 2 +-
> drivers/scsi/BusLogic.c | 2 +-
> drivers/scsi/a100u2w.c | 2 +-
> drivers/scsi/a2091.c | 2 +-
> drivers/scsi/a3000.c | 2 +-
> drivers/scsi/aacraid/linit.c | 2 +-
> drivers/scsi/advansys.c | 6 +++---
> drivers/scsi/aha152x.c | 2 +-
> drivers/scsi/aha1542.c | 2 +-
> drivers/scsi/aha1740.c | 2 +-
> drivers/scsi/aic7xxx/aic79xx_osm.c | 2 +-
> drivers/scsi/aic7xxx/aic7xxx_osm.c | 2 +-
> drivers/scsi/aic94xx/aic94xx_init.c | 2 +-
> drivers/scsi/am53c974.c | 2 +-
> drivers/scsi/arcmsr/arcmsr_hba.c | 3 ++-
> drivers/scsi/arm/acornscsi.c | 2 +-
> drivers/scsi/arm/arxescsi.c | 2 +-
> drivers/scsi/arm/cumana_1.c | 2 +-
> drivers/scsi/arm/cumana_2.c | 2 +-
> drivers/scsi/arm/eesox.c | 2 +-
> drivers/scsi/arm/oak.c | 2 +-
> drivers/scsi/arm/powertec.c | 2 +-
> drivers/scsi/atari_scsi.c | 2 +-
> drivers/scsi/atp870u.c | 2 +-
> drivers/scsi/bfa/bfad_im.c | 2 +-
> drivers/scsi/csiostor/csio_init.c | 4 ++--
> drivers/scsi/dc395x.c | 2 +-
> drivers/scsi/dmx3191d.c | 2 +-
> drivers/scsi/elx/efct/efct_xport.c | 4 ++--
> drivers/scsi/esas2r/esas2r_main.c | 2 +-
> drivers/scsi/fdomain.c | 2 +-
> drivers/scsi/fnic/fnic_main.c | 2 +-
> drivers/scsi/g_NCR5380.c | 2 +-
> drivers/scsi/gvp11.c | 2 +-
> drivers/scsi/hisi_sas/hisi_sas_main.c | 2 +-
> drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 2 +-
> drivers/scsi/hosts.c | 6 ++++--
> drivers/scsi/hpsa.c | 2 +-
> drivers/scsi/hptiop.c | 2 +-
> drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
> drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +-
> drivers/scsi/imm.c | 2 +-
> drivers/scsi/initio.c | 2 +-
> drivers/scsi/ipr.c | 2 +-
> drivers/scsi/ips.c | 2 +-
> drivers/scsi/isci/init.c | 2 +-
> drivers/scsi/jazz_esp.c | 2 +-
> drivers/scsi/libiscsi.c | 2 +-
> drivers/scsi/lpfc/lpfc_init.c | 2 +-
> drivers/scsi/mac53c94.c | 2 +-
> drivers/scsi/mac_esp.c | 2 +-
> drivers/scsi/mac_scsi.c | 2 +-
> drivers/scsi/megaraid.c | 2 +-
> drivers/scsi/megaraid/megaraid_mbox.c | 2 +-
> drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
> drivers/scsi/mesh.c | 2 +-
> drivers/scsi/mpi3mr/mpi3mr_os.c | 2 +-
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
> drivers/scsi/mvme147.c | 2 +-
> drivers/scsi/mvsas/mv_init.c | 2 +-
> drivers/scsi/mvumi.c | 2 +-
> drivers/scsi/myrb.c | 2 +-
> drivers/scsi/myrs.c | 2 +-
> drivers/scsi/ncr53c8xx.c | 2 +-
> drivers/scsi/nsp32.c | 2 +-
> drivers/scsi/pcmcia/nsp_cs.c | 2 +-
> drivers/scsi/pcmcia/qlogic_stub.c | 2 +-
> drivers/scsi/pcmcia/sym53c500_cs.c | 2 +-
> drivers/scsi/pm8001/pm8001_init.c | 2 +-
> drivers/scsi/pmcraid.c | 2 +-
> drivers/scsi/ppa.c | 2 +-
> drivers/scsi/ps3rom.c | 2 +-
> drivers/scsi/qla1280.c | 2 +-
> drivers/scsi/qla2xxx/qla_mid.c | 2 +-
> drivers/scsi/qla2xxx/qla_os.c | 2 +-
> drivers/scsi/qlogicfas.c | 2 +-
> drivers/scsi/qlogicpti.c | 2 +-
> drivers/scsi/scsi_debug.c | 2 +-
> drivers/scsi/sgiwd93.c | 2 +-
> drivers/scsi/smartpqi/smartpqi_init.c | 2 +-
> drivers/scsi/snic/snic_main.c | 2 +-
> drivers/scsi/stex.c | 2 +-
> drivers/scsi/storvsc_drv.c | 2 +-
> drivers/scsi/sun3_scsi.c | 2 +-
> drivers/scsi/sun3x_esp.c | 2 +-
> drivers/scsi/sun_esp.c | 2 +-
> drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +-
> drivers/scsi/virtio_scsi.c | 2 +-
> drivers/scsi/vmw_pvscsi.c | 2 +-
> drivers/scsi/wd719x.c | 2 +-
> drivers/scsi/xen-scsifront.c | 2 +-
> drivers/scsi/zorro_esp.c | 2 +-
> include/scsi/libfc.h | 2 +-
> include/scsi/scsi_host.h | 3 ++-
> 97 files changed, 107 insertions(+), 103 deletions(-)
>
Quite a lot of churn for such a (relatively) simple change.
I think it might be better to introduce a new function
(scsi_host_alloc_node() ?) with the additional parameter,
and make scsi_host_alloc() a wrapper around that.
That will reduce the size of this patch immensely.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.com +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH v3 1/4] scsi: scan: allocate sdev and starget on the NUMA node of the host adapter
From: Hannes Reinecke @ 2026-06-10 6:00 UTC (permalink / raw)
To: Sumit Saxena, Martin K . Petersen, Jens Axboe
Cc: James E . J . Bottomley, linux-scsi, linux-block, Adam Radford,
Khalid Aziz, Adaptec OEM Raid Solutions, Matthew Wilcox,
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, James Rizzo
In-Reply-To: <20260609121806.2121755-2-sumit.saxena@broadcom.com>
On 6/9/26 14:18, Sumit Saxena wrote:
> From: James Rizzo <james.rizzo@broadcom.com>
>
> When a host adapter is attached to a specific NUMA node, allocating
> scsi_device and scsi_target via kzalloc() may place them on a remote
> node. All hot-path I/O accesses to these structures then cross the NUMA
> interconnect, adding latency and consuming inter-node bandwidth.
>
> Use kzalloc_node() with dev_to_node(shost->dma_dev) so allocations land
> on the same node as the HBA, reducing cross-node traffic and improving
> I/O performance on NUMA systems.
>
> Signed-off-by: James Rizzo <james.rizzo@broadcom.com>
> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> ---
> drivers/scsi/scsi_scan.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.com +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH v3 3/4] block: drop shared-tag fairness throttling
From: Christoph Hellwig @ 2026-06-10 6:14 UTC (permalink / raw)
To: Sumit Saxena
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,
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: <20260609121806.2121755-4-sumit.saxena@broadcom.com>
Just dropping the fairness was rejected before and there is no
explanation here on why any of that has changed.
On Tue, Jun 09, 2026 at 05:48:02PM +0530, Sumit Saxena wrote:
> From: Bart Van Assche <bvanassche@acm.org>
>
> Original patch [1] by Bart Van Assche; this version is rebased onto the
> current tree. In testing it improves IOPS by roughly 16-18% by removing
> the fair-sharing throttle on shared tag queues.
>
> This patch removes the following code and structure members:
> - The function hctx_may_queue().
> - blk_mq_hw_ctx.nr_active and request_queue.nr_active_requests_shared_tags
> and also all the code that modifies these two member variables.
.. and besides that, this commit message is still entirely useless
as it doesn't explain any of the thoughts of why this change is safe
and desirable. While the mechanics above are totally obvious from
the code change itself.
^ permalink raw reply
* Re: [PATCH v2 00/14] list: Prepare entry iterators to cache cursor state
From: Kaitao Cheng @ 2026-06-10 6:14 UTC (permalink / raw)
To: Christian König, Andy Shevchenko
Cc: Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
Davidlohr Bueso, Paul E . McKenney, Josh Triplett, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Liam Girdwood, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Eddie James, Mark Brown, Maxime Coquelin, Alexandre Torgue,
Laxman Dewangan, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Matthew Auld,
Matthew Brost, Waiman Long, drbd-dev, linux-block,
linux1394-devel, dri-devel, intel-gfx, linux-spi, linux-stm32,
linux-arm-kernel, linux-tegra, linux-sound, linux-kernel,
Andrew Morton, Randy Dunlap, Christian Brauner, David Howells,
Luca Ceresoli, Kaito Cheng, Muchun Song, Philipp Reisner,
Lars Ellenberg, Christoph Böhmwalder, Jens Axboe,
Takashi Sakamoto, Andrzej Hajda, Jaroslav Kysela, Takashi Iwai
In-Reply-To: <bd0b7393-8ccb-4d67-8bfc-18c68347122c@amd.com>
在 2026/6/9 18:33, Christian König 写道:
> On 6/9/26 08:13, Kaitao Cheng wrote:
>> From: Kaito Cheng <chengkaitao@kylinos.cn>
>>
>> This series prepares for, and then updates, the list_for_each_entry()
>> family so the common entry iterators cache their next or previous cursor
>> before the loop body runs.
>
> Why in the world would we want to do that?
>
> The safe and non-safe variants have very distinct use cases and that is completely intentional.
>
> What we could improve maybe is the documentation, from my experience an astonishing large amount of people have misconceptions about the safe variants.
>
>> The first 13 patches open-code loops that intentionally depend on the
>> old "derive the next entry from the current cursor at the end of the
>> iteration" behaviour. These loops append work to the list being walked,
>> restart traversal after dropping a lock, skip an entry consumed by the
>> current iteration, or otherwise adjust the cursor in the loop body.
>
> Well I have to clearly reject the changes for subsystems/components I'm maintaining, that just looks horrible to me and I clearly don't see a good reason for that.
Hi Christian and Andy Shevchenko,
Thanks for taking a look. I would like to clarify the point you raised.
The reason I started looking at this is the original motivation behind
the _safe() variants. They exist because some users need to remove, move
or otherwise consume the current entry while walking the list. In that
case the next cursor has to be preserved before the loop body can modify
the current entry.
The unfortunate part is that this could not be expressed with the
existing list_for_each_entry() interface without changing its calling
convention. The _safe() variants had to grow an extra argument for the
temporary cursor, and that is why we ended up with a separate family of
macros.
But conceptually, the distinction does not have to be exposed as two
different iterator families forever. The difference is an implementation
detail: whether the iterator keeps the next/previous cursor before the
body runs. This series makes the common list_for_each_entry() iterators
do that internally, so the safe and non-safe forms can effectively be
folded together, or at least the need for a separate public _safe()
interface becomes much weaker.
There is also a usability issue with the current _safe() interface. The
caller is forced to define a temporary cursor outside the macro and pass
it in, even though almost all users never use that cursor directly. It is
just boilerplate required by the macro implementation. I find that
redundant and awkward: the temporary cursor is an internal detail of the
iteration, but every caller has to spell it out.
With the updated list_for_each_entry() implementation, that extra cursor
can be kept inside the iterator itself. Callers that only want to walk
the list, including callers that delete or consume the current entry, no
longer need to carry an otherwise-unused temporary variable just to make
the macro work.
>>
>> The final patch changes include/linux/list.h to keep a private cursor in
>> the common entry iterators while preserving the public macro interface.
>> The safe variants remain available when callers need the temporary
>> cursor explicitly or have stronger mutation requirements.
>>
>> Changes in v2 (Muchun Song, Andy Shevchenko):
>> - Drop the list_for_each_entry_mutable*() helpers from v1 and make the
>> cursor change directly in the existing list_for_each_entry*() helpers.
>> - Open-code special list walks that rely on updating the loop cursor in
>> the body, preserving their existing traversal semantics.
>>
>> Link to v1:
>> https://lore.kernel.org/all/20260529082149.76764-1-kaitao.cheng@linux.dev/
>>
>> Kaitao Cheng (14):
>> drbd: Open-code transfer log list walk
>> firewire: core: Open-code topology list walk
>> drm/bridge: Open-code bridge chain list walks
>> drm/i915/gt: Open-code active timeline walk
>> drm/i915: Open-code DFS dependency list walk
>> drm/ttm: Open-code reservation list walk
>> spi: fsi: Open-code message transfer walk
>> spi: stm32-ospi: Open-code message transfer walk
>> spi: stm32-qspi: Open-code message transfer walk
>> spi: tegra210-quad: Open-code message transfer walk
>> locking/locktorture: Open-code ww mutex list walk
>> locking/ww_mutex: Open-code stress reorder list walk
>> ASoC: dapm: Open-code widget invalidation walk
>> list: Cache cursors in entry iterators
>>
>> drivers/block/drbd/drbd_debugfs.c | 4 ++-
>> drivers/firewire/core-topology.c | 4 ++-
>> drivers/gpu/drm/drm_bridge.c | 7 ++--
>> drivers/gpu/drm/i915/gt/intel_reset.c | 4 ++-
>> drivers/gpu/drm/i915/i915_scheduler.c | 4 ++-
>> drivers/gpu/drm/ttm/ttm_execbuf_util.c | 4 ++-
>> drivers/spi/spi-fsi.c | 5 ++-
>> drivers/spi/spi-stm32-ospi.c | 4 ++-
>> drivers/spi/spi-stm32-qspi.c | 5 ++-
>> drivers/spi/spi-tegra210-quad.c | 4 ++-
>> include/linux/list.h | 46 ++++++++++++++++++++------
>> kernel/locking/locktorture.c | 4 ++-
>> kernel/locking/test-ww_mutex.c | 4 ++-
>> sound/soc/soc-dapm.c | 4 ++-
>> 14 files changed, 78 insertions(+), 25 deletions(-)
>>
>> --
>> 2.43.0
>>
>
--
Thanks
Kaitao Cheng
^ permalink raw reply
* Re: [PATCH v3 3/4] block: drop shared-tag fairness throttling
From: Hannes Reinecke @ 2026-06-10 6:18 UTC (permalink / raw)
To: Sumit Saxena, Martin K . Petersen, Jens Axboe
Cc: 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: <20260609121806.2121755-4-sumit.saxena@broadcom.com>
On 6/9/26 14:18, Sumit Saxena wrote:
> From: Bart Van Assche <bvanassche@acm.org>
>
> Original patch [1] by Bart Van Assche; this version is rebased onto the
> current tree. In testing it improves IOPS by roughly 16-18% by removing
> the fair-sharing throttle on shared tag queues.
>
> This patch removes the following code and structure members:
> - The function hctx_may_queue().
> - blk_mq_hw_ctx.nr_active and request_queue.nr_active_requests_shared_tags
> and also all the code that modifies these two member variables.
>
> [1]: https://lore.kernel.org/linux-block/20240529213921.3166462-1-bvanassche@acm.org/
>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> ---
> block/blk-core.c | 2 -
> block/blk-mq-debugfs.c | 22 ++++++++-
> block/blk-mq-tag.c | 4 --
> block/blk-mq.c | 17 +------
> block/blk-mq.h | 100 -----------------------------------------
> include/linux/blk-mq.h | 6 ---
> include/linux/blkdev.h | 2 -
> 7 files changed, 22 insertions(+), 131 deletions(-)
>
What tests did you perform?
I'm pretty sure you see an improvement when having just a few drives,
but what about having a lot of them (ie tens of drives)?
The whole point of this was to increase fairness between drives, so
of course removing it will make an individual drive going faster ...
Maybe it's an idea to move the fairness algorithm into an I/O scheduler;
that way we can keep the original behaviour yet get the performance
increase if people want it.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH v3 4/4] scsi: use percpu counters for iostat counters in struct scsi_device
From: Hannes Reinecke @ 2026-06-10 6:21 UTC (permalink / raw)
To: Sumit Saxena, Martin K . Petersen, Jens Axboe
Cc: 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, John Garry
In-Reply-To: <20260609121806.2121755-5-sumit.saxena@broadcom.com>
On 6/9/26 14:18, Sumit Saxena wrote:
> iorequest_cnt and iodone_cnt are updated on every command dispatch and
> completion, often from different CPUs on high queue depth workloads.
> Using adjacent atomic_t fields causes cache line contention between the
> submission and completion paths.
>
> Extend the same treatment to ioerr_cnt and iotmo_cnt so all four iostat
> counters in struct scsi_device use struct percpu_counter.
>
> Suggested-by: John Garry <john.g.garry@oracle.com>
> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> ---
> drivers/scsi/scsi_error.c | 4 ++--
> drivers/scsi/scsi_lib.c | 10 +++++-----
> drivers/scsi/scsi_scan.c | 8 ++++++++
> drivers/scsi/scsi_sysfs.c | 23 ++++++++++++++---------
> drivers/scsi/sd.c | 2 +-
> include/scsi/scsi_device.h | 9 +++++----
> 6 files changed, 35 insertions(+), 21 deletions(-)
>
Good idea.
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* Re: [PATCH RFC 7/8] erofs: open via dedicated fs bdev helpers
From: Gao Xiang @ 2026-06-10 6:55 UTC (permalink / raw)
To: Christian Brauner
Cc: Jens Axboe, Alexander Viro, linux-block, linux-kernel,
linux-fsdevel, Carlos Maiolino, linux-xfs, Chris Mason,
David Sterba, linux-btrfs, Theodore Ts'o, linux-ext4,
Gao Xiang, linux-erofs, Christoph Hellwig, Jan Kara
In-Reply-To: <20260603-nieder-ausdehnen-siebdruck-aa96f40ebec6@brauner>
Hi Christian,
On 2026/6/3 21:42, Christian Brauner wrote:
>> May I ask if it's an urgent 7.2 work? If not, I could
>
> No no, it's way too late for that this cycle.
>
>> make a preparation patch for the upcoming 7.2 cycle
>> to handle erofs_map_dev() failure here so you don't
>> need to bother with this in this patchset.
>
> Sounds good. I take it you can just do this yourself without me.
>
>> I will seek more time to resolve the recent todos
>
> Thanks!
>
>> yet always intercepted by other unrelated stuffs.
>
> :)
I removed .shutdown() and .remove_bdev() implementations since I
think it doesn't quite seem necessary for immutable fses, but
would like to know your thoughts too, my overall own comments are
documented in the commit message below:
From 933f6c6f2e704116d9a15815c880196bec7b9ee3 Mon Sep 17 00:00:00 2001
From: Christian Brauner <brauner@kernel.org>
Date: Tue, 2 Jun 2026 12:10:13 +0200
Subject: [PATCH] erofs: open via dedicated fs bdev helpers
Route opens through fs_bdev_file_open_by_path() so each external device
is registered against the correct superblock, and convert the matching
releases.
Gao Xiang: I think typical immutable filesystems don't need .shutdown()
and .remove_bdev() for the following reasons:
- blk_mark_disk_dead() sets GD_DEAD in advance of fs_bdev_mark_dead()
so that the following bios will fail immediately; block_device
references are still valid so it seems overkill to handle dead
blockdevs in the deep filesystem I/O submission path.
- Immutable filesystems like EROFS don't have write paths and journals,
so they don't need to block writes (i.e., new dirty pages), metadata
changes, and abort journals.
- The comment above loop_change_fd() documents a valid read-only use
case we need to support anyway, but it calls disk_force_media_change()
which will call fs_bdev_mark_dead() later: we don't want loop_change_fd()
shutdowns the active filesystems and return -EIO unconditionally.
Currently I think the default behavior (shrink_dcache_sb + evict_inodes)
in fs_bdev_mark_dead() is enough for immutable filesystems, tried to
document in the commit here for later reference.
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
---
fs/erofs/super.c | 35 +++++++++++++++++++++++------------
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 802add6652fd..def9cbfbc9d8 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -153,8 +153,8 @@ static int erofs_init_device(struct erofs_buf *buf, struct super_block *sb,
} else if (!sbi->devs->flatdev) {
file = erofs_is_fileio_mode(sbi) ?
filp_open(dif->path, O_RDONLY | O_LARGEFILE, 0) :
- bdev_file_open_by_path(dif->path,
- BLK_OPEN_READ, sb->s_type, NULL);
+ fs_bdev_file_open_by_path(dif->path,
+ BLK_OPEN_READ, sb->s_type, sb);
if (IS_ERR(file)) {
if (file == ERR_PTR(-ENOTBLK))
return -EINVAL;
@@ -843,11 +843,16 @@ static int erofs_fc_reconfigure(struct fs_context *fc)
static int erofs_release_device_info(int id, void *ptr, void *data)
{
+ struct super_block *sb = data;
struct erofs_device_info *dif = ptr;
fs_put_dax(dif->dax_dev, NULL);
- if (dif->file)
- fput(dif->file);
+ if (dif->file) {
+ if (S_ISBLK(file_inode(dif->file)->i_mode))
+ fs_bdev_file_release(dif->file, sb);
+ else
+ fput(dif->file);
+ }
erofs_fscache_unregister_cookie(dif->fscache);
dif->fscache = NULL;
kfree(dif->path);
@@ -855,18 +860,19 @@ static int erofs_release_device_info(int id, void *ptr, void *data)
return 0;
}
-static void erofs_free_dev_context(struct erofs_dev_context *devs)
+static void erofs_free_dev_context(struct erofs_dev_context *devs,
+ struct super_block *sb)
{
if (!devs)
return;
- idr_for_each(&devs->tree, &erofs_release_device_info, NULL);
+ idr_for_each(&devs->tree, &erofs_release_device_info, sb);
idr_destroy(&devs->tree);
kfree(devs);
}
-static void erofs_sb_free(struct erofs_sb_info *sbi)
+static void erofs_sb_free(struct erofs_sb_info *sbi, struct super_block *sb)
{
- erofs_free_dev_context(sbi->devs);
+ erofs_free_dev_context(sbi->devs, sb);
kfree(sbi->fsid);
kfree_sensitive(sbi->domain_id);
if (sbi->dif0.file)
@@ -879,8 +885,13 @@ static void erofs_fc_free(struct fs_context *fc)
{
struct erofs_sb_info *sbi = fc->s_fs_info;
- if (sbi) /* free here if an error occurs before transferring to sb */
- erofs_sb_free(sbi);
+ /*
+ * Freed here only if an error occurs before the sb is set up; at that
+ * point no block-backed device has been claimed (that happens in
+ * fill_super), so the NULL sb never reaches fs_bdev_file_release().
+ */
+ if (sbi)
+ erofs_sb_free(sbi, NULL);
}
static const struct fs_context_operations erofs_context_ops = {
@@ -936,7 +947,7 @@ static void erofs_kill_sb(struct super_block *sb)
erofs_drop_internal_inodes(sbi);
fs_put_dax(sbi->dif0.dax_dev, NULL);
erofs_fscache_unregister_fs(sb);
- erofs_sb_free(sbi);
+ erofs_sb_free(sbi, sb);
sb->s_fs_info = NULL;
}
@@ -948,7 +959,7 @@ static void erofs_put_super(struct super_block *sb)
erofs_shrinker_unregister(sb);
erofs_xattr_prefixes_cleanup(sb);
erofs_drop_internal_inodes(sbi);
- erofs_free_dev_context(sbi->devs);
+ erofs_free_dev_context(sbi->devs, sb);
sbi->devs = NULL;
erofs_fscache_unregister_fs(sb);
}
--
2.43.5
^ permalink raw reply related
* Re: [Kernel Bug] INFO: rcu detected stall in disk_check_events
From: Longxing Li @ 2026-06-10 7:05 UTC (permalink / raw)
To: Jens Axboe; +Cc: syzkaller, linux-block, linux-kernel
In-Reply-To: <8b2f0830-23cf-4f6f-89a4-1390cb0f2e88@kernel.dk>
sorry for not containing the report text in last email. the report is
as follows:
hrtimer: interrupt took 4316899 ns
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-0): P10/1:b..l
rcu: (detected by 0, t=13059 jiffies, g=30961, q=723 ncpus=1)
task:kworker/0:1 state:R running task stack:21112 pid:10
tgid:10 ppid:2 task_flags:0x4208060 flags:0x00080000
Workqueue: events_freezable_pwr_efficient disk_events_workfn
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5298 [inline]
__schedule+0x1006/0x5f00 kernel/sched/core.c:6911
preempt_schedule_irq+0x51/0x90 kernel/sched/core.c:7238
irqentry_exit+0x1e4/0x740 kernel/entry/common.c:239
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:sbitmap_get+0x0/0x370 lib/sbitmap.c:282
Code: fd eb a0 48 89 ef e8 6f 19 43 fd eb db 48 89 ef e8 75 18 43 fd
eb b1 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f
1e fa 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 18 e8
RSP: 0018:ffffc900001bf538 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff84924c1d
RDX: ffff88801da925c0 RSI: ffffffff86168ec8 RDI: ffff888024fea030
RBP: ffff888024fea000 R08: ffff88801dba68d8 R09: ffffed1004a0150a
R10: 0000000000000001 R11: 00000000000003f1 R12: ffff88802500a800
R13: ffff888020e95348 R14: ffff888024fea030 R15: ffff888024fea040
scsi_dev_queue_ready drivers/scsi/scsi_lib.c:1376 [inline]
scsi_mq_get_budget+0x74/0x4d0 drivers/scsi/scsi_lib.c:1787
blk_mq_get_dispatch_budget block/blk-mq.h:274 [inline]
blk_mq_prep_dispatch_rq block/blk-mq.c:2052 [inline]
blk_mq_dispatch_rq_list+0x1dc/0x1bc0 block/blk-mq.c:2139
__blk_mq_sched_dispatch_requests+0x215/0x1470 block/blk-mq-sched.c:299
blk_mq_sched_dispatch_requests+0xd7/0x1b0 block/blk-mq-sched.c:329
blk_mq_run_hw_queue+0x3da/0x650 block/blk-mq.c:2386
blk_execute_rq+0x194/0x410 block/blk-mq.c:1523
scsi_execute_cmd+0x42e/0xeb0 drivers/scsi/scsi_lib.c:332
sr_get_events drivers/scsi/sr.c:177 [inline]
sr_check_events+0x1b3/0xad0 drivers/scsi/sr.c:218
cdrom_update_events drivers/cdrom/cdrom.c:1464 [inline]
cdrom_check_events+0x68/0x110 drivers/cdrom/cdrom.c:1474
sr_block_check_events+0xc3/0x100 drivers/scsi/sr.c:573
disk_check_events+0xc7/0x420 block/disk-events.c:193
process_one_work+0x9de/0x1c60 kernel/workqueue.c:3288
process_scheduled_works kernel/workqueue.c:3371 [inline]
worker_thread+0x693/0xeb0 kernel/workqueue.c:3452
kthread+0x38d/0x4a0 kernel/kthread.c:436
ret_from_fork+0x942/0xe50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: rcu_preempt kthread starved for 13059 jiffies! g30961 f0x0
RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now
expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task stack:26712 pid:16
tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5298 [inline]
__schedule+0x1006/0x5f00 kernel/sched/core.c:6911
__schedule_loop kernel/sched/core.c:6993 [inline]
schedule+0xe7/0x3a0 kernel/sched/core.c:7008
schedule_timeout+0x113/0x280 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x18c/0x7e0 kernel/rcu/tree.c:2095
rcu_gp_kthread+0x1aa/0x260 kernel/rcu/tree.c:2297
kthread+0x38d/0x4a0 kernel/kthread.c:436
ret_from_fork+0x942/0xe50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: Stack dump where RCU GP kthread last ran:
CPU: 0 UID: 0 PID: 9798 Comm: syz-executor.6 Not tainted 7.0.6 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:orc_find arch/x86/kernel/unwind_orc.c:228 [inline]
RIP: 0010:unwind_next_frame+0x1f9/0x20c0 arch/x86/kernel/unwind_orc.c:510
Code: 41 89 c2 39 d0 0f 83 0d 16 00 00 48 ba 00 00 00 00 00 fc ff df
89 c1 48 8d 3c 8d 70 fb 0f 92 48 89 fe 48 c1 ee 03 0f b6 34 16 <48> 89
fa 83 e2 07 83 c2 03 40 38 f2 7c 31 40 84 f6 74 2c 48 89 4c
RSP: 0018:ffffc900000072d0 EFLAGS: 00000a06
RAX: 0000000000011bf6 RBX: 0000000000000002 RCX: 0000000000011bf6
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffffffff92146b48
RBP: ffffc90000007388 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000011bf6 R11: 00000000000a7f57 R12: ffffc90000007390
R13: ffffc90000007340 R14: ffffc90000007375 R15: ffffffff821bf607
FS: 00000000281a7480(0000) GS:ffff888097781000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000031883988 CR3: 000000004ec61000 CR4: 0000000000752ef0
PKRU: 55555554
Call Trace:
<IRQ>
arch_stack_walk+0x86/0xf0 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0x8e/0xc0 kernel/stacktrace.c:122
save_stack+0x151/0x1e0 mm/page_owner.c:165
__set_page_owner+0x8f/0x570 mm/page_owner.c:341
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x134/0x160 mm/page_alloc.c:1897
prep_new_page mm/page_alloc.c:1905 [inline]
get_page_from_freelist+0xde8/0x2ae0 mm/page_alloc.c:3970
__alloc_pages_slowpath mm/page_alloc.c:4813 [inline]
__alloc_frozen_pages_noprof+0x653/0x27e0 mm/page_alloc.c:5271
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab mm/slub.c:3481 [inline]
new_slab+0xa6/0x6b0 mm/slub.c:3539
refill_objects+0x256/0x3f0 mm/slub.c:7179
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x1b1/0x690 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
kmem_cache_alloc_node_noprof+0x4d7/0x6e0 mm/slub.c:4918
__alloc_skb+0x14c/0x740 net/core/skbuff.c:702
alloc_skb include/linux/skbuff.h:1383 [inline]
ndisc_alloc_skb+0xd7/0x530 net/ipv6/ndisc.c:420
ndisc_send_rs+0x70/0x690 net/ipv6/ndisc.c:706
addrconf_rs_timer+0x3ee/0x860 net/ipv6/addrconf.c:4041
call_timer_fn+0x1a5/0x670 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers+0x6d2/0xb20 kernel/time/timer.c:2373
__run_timer_base kernel/time/timer.c:2385 [inline]
__run_timer_base kernel/time/timer.c:2377 [inline]
run_timer_base+0xc5/0x120 kernel/time/timer.c:2394
run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2404
handle_softirqs+0x1d3/0x9b0 kernel/softirq.c:622
do_softirq kernel/softirq.c:523 [inline]
do_softirq+0xac/0xe0 kernel/softirq.c:510
</IRQ>
<TASK>
__local_bh_enable_ip+0x100/0x120 kernel/softirq.c:450
spin_unlock_bh include/linux/spinlock.h:395 [inline]
crypto_acomp_unlock_stream_bh include/crypto/internal/acompress.h:201 [inline]
scomp_acomp_comp_decomp+0x574/0xd50 crypto/scompress.c:257
crypto_acomp_compress+0x14c/0x540 crypto/acompress.c:287
zswap_compress mm/zswap.c:885 [inline]
zswap_store_page mm/zswap.c:1422 [inline]
zswap_store+0xa25/0x2710 mm/zswap.c:1533
swap_writeout+0x3d8/0xd80 mm/page_io.c:275
writeout mm/vmscan.c:652 [inline]
pageout mm/vmscan.c:699 [inline]
shrink_folio_list+0x3d4e/0x4b10 mm/vmscan.c:1425
evict_folios+0x79a/0x1b20 mm/vmscan.c:4718
try_to_shrink_lruvec+0x59a/0x9d0 mm/vmscan.c:4881
shrink_one+0x309/0x690 mm/vmscan.c:4926
shrink_many mm/vmscan.c:4989 [inline]
lru_gen_shrink_node mm/vmscan.c:5067 [inline]
shrink_node+0x24ee/0x3c90 mm/vmscan.c:6047
shrink_zones mm/vmscan.c:6300 [inline]
do_try_to_free_pages+0x373/0x1830 mm/vmscan.c:6362
try_to_free_pages+0x24e/0x6a0 mm/vmscan.c:6601
__perform_reclaim mm/page_alloc.c:4432 [inline]
__alloc_pages_direct_reclaim mm/page_alloc.c:4454 [inline]
__alloc_pages_slowpath mm/page_alloc.c:4854 [inline]
__alloc_frozen_pages_noprof+0x8e0/0x27e0 mm/page_alloc.c:5271
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab mm/slub.c:3489 [inline]
new_slab+0x264/0x6b0 mm/slub.c:3539
refill_objects+0x256/0x3f0 mm/slub.c:7179
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x1b1/0x690 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
__do_kmalloc_node mm/slub.c:5259 [inline]
__kmalloc_noprof+0x68b/0x850 mm/slub.c:5272
kmalloc_noprof include/linux/slab.h:954 [inline]
tomoyo_realpath_from_path+0xc3/0x600 security/tomoyo/realpath.c:251
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_check_open_permission+0x298/0x3a0 security/tomoyo/file.c:776
tomoyo_file_open+0x69/0x90 security/tomoyo/tomoyo.c:334
security_file_open+0x88/0x200 security/security.c:2739
do_dentry_open+0x576/0x1680 fs/open.c:926
vfs_open+0x82/0x3f0 fs/open.c:1081
do_open fs/namei.c:4677 [inline]
path_openat+0x1fc5/0x2cf0 fs/namei.c:4836
do_file_open+0x216/0x470 fs/namei.c:4865
do_sys_openat2+0xe6/0x250 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x13f/0x1f0 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x11b/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x470aa4
Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 16 db 02 00 44 8b 54 24 0c
44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d
00 f0 ff ff 77 34 44 89 c7 89 44 24 0c e8 58 db 02 00 8b 44
RSP: 002b:00007ffd1fccdce0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007ffd1fccddd0 RCX: 0000000000470aa4
RDX: 0000000000000002 RSI: 00007ffd1fccde10 RDI: 00000000ffffff9c
RBP: 00007ffd1fccde10 R08: 0000000000000000 R09: 00007ffd1fccdbf0
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002
R13: 000000000002c3ab R14: 000000000002c398 R15: 0000000000000005
</TASK>
Jens Axboe <axboe@kernel.dk> 于2026年6月9日周二 20:41写道：
>
> On 6/9/26 5:52 AM, Longxing Li wrote:
> > Dear Linux kernel developers and maintainers,
> >
> > We would like to report a new kernel bug found by our tool. INFO: rcu
> > detected stall in disk_check_events. Details are as follows.
> >
> > Kernel commit: v7.0.6
> > Kernel config: see attachment
> > report: see attachment
> >
> > We are currently analyzing the root cause and working on a
> > reproducible PoC. We will provide further updates in this thread as
> > soon as we have more information.
>
> Please include pertinent information in the email rather than some
> shared drive somewhere.
>
> --
> Jens Axboe
>
^ permalink raw reply
* Re: [PATCH] rust: block: require `Sync` for `Operations::QueueData`
From: Alice Ryhl @ 2026-06-10 7:08 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Boqun Feng, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Trevor Gross, Danilo Krummrich, Jens Axboe,
Daniel Almeida, linux-block, rust-for-linux, linux-kernel
In-Reply-To: <20260608-queue-data-sync-v1-1-0efff051aaf3@kernel.org>
On Mon, Jun 08, 2026 at 10:24:34AM +0200, Andreas Hindborg wrote:
> The queue data installed in a `GenDisk` is stored in the request queue and
> handed back to the driver as a shared borrow through the `queue_rq` and
> `commit_rqs` callbacks. Both callbacks obtain that borrow via
> `ForeignOwnable::borrow` and may execute concurrently on several CPUs,
> since the block layer runs one hardware queue per CPU. That means a shared
> reference to the same queue data can be live on multiple threads at once,
> which is only sound when the referent is `Sync`.
>
> The initial `GenDisk` private data support omitted this bound, so a
> driver could install a non-`Sync` type as queue data and then access
> it concurrently from multiple CPUs without synchronization. Add a
> `Sync` bound to the `QueueData` associated type to rule that out.
>
> Fixes: 90d952fac8ac ("rust: block: add `GenDisk` private data support")
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells
From: Krzysztof Kozlowski @ 2026-06-10 7:16 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, Bartosz Golaszewski
In-Reply-To: <20260609-block-as-nvmem-v4-2-45712e6b22c6@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 09:52:27AM +0200, Loic Poulain wrote:
> Document the NVMEM cells supported by the ath10k driver, the
> mac-address, pre-calibration data, and calibration data.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd558ab792524be9afec8b79272d1c87..7391df5e7071e626af4c64b9919d48c41ac09f1e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -92,6 +92,22 @@ properties:
>
> ieee80211-freq-limit: true
>
> + nvmem-cells:
> + minItems: 1
> + maxItems: 3
> + description: |
If there is going to be resend:
Do not need '|' unless you need to preserve formatting.
> + References to nvmem cells for MAC address and/or calibration data.
> + Supported cell names are mac-address, calibration, and pre-calibration.
> +
> + nvmem-cell-names:
> + minItems: 1
> + maxItems: 3
> + items:
> + enum:
> + - mac-address
> + - calibration
> + - pre-calibration
This means you expect random order with variable number of items. Is
that intentional? If yes, please provide short explanation in the commit
msg.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1] floppy: Drop unused pnp driver data
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-10 7:27 UTC (permalink / raw)
To: Denis Efremov, Jens Axboe; +Cc: linux-block, linux-kernel
The pnp_device_id array is only used for module data to support
auto-loading the floppy module. So the .driver_data member is unused and
this assignment can be dropped.
While touching that array, align the coding style to what is used most
for these.
This patch doesn't modify the compiled array, only its representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
I intend to change struct pnp_device_id and for that it's required that
.driver_data is not assigned using a list initializer. Instead of
converting it to a named initializer, drop the assignment as the value
is unused. So this is both a cleanup and a preparation for a later patch
series.
See
https://lore.kernel.org/all/cover.1779878004.git.u.kleine-koenig@baylibre.com/
for a more verbose description on the mentioned change to struct
pnp_device_id (though this is about platform_device_id, but the idea
here is the same).
Best regards
Uwe
drivers/block/floppy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 0509746f8aed..dca495be0683 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -5012,8 +5012,8 @@ MODULE_LICENSE("GPL");
/* This doesn't actually get used other than for module information */
static const struct pnp_device_id floppy_pnpids[] = {
- {"PNP0700", 0},
- {}
+ { .id = "PNP0700" },
+ { }
};
MODULE_DEVICE_TABLE(pnp, floppy_pnpids);
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 21/27] null_blk: Enable lock context analysis
From: Nilay Shroff @ 2026-06-10 7:28 UTC (permalink / raw)
To: Bart Van Assche, Jens Axboe
Cc: linux-block, Christoph Hellwig, Marco Elver, Keith Busch,
Damien Le Moal, Chaitanya Kulkarni, Johannes Thumshirn,
Genjian Zhang, Kees Cook
In-Reply-To: <b70422c6f243b9275e336430071b52eb92dd40c4.1781042470.git.bvanassche@acm.org>
On 6/10/26 3:35 AM, Bart Van Assche wrote:
> Add __must_hold() annotations where these are missing. Annotate two
> functions that use conditional locking with __context_unsafe(). Enable lock
> context analysis in the Makefile.
>
> Signed-off-by: Bart Van Assche<bvanassche@acm.org>
> ---
Looks good to me.
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH 00/27] Enable lock context analysis in drivers/block/
From: Marco Elver @ 2026-06-10 7:31 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Bart Van Assche, Jens Axboe, linux-block
In-Reply-To: <aij3e1WKFQunNUS2@infradead.org>
On Wed, 10 Jun 2026 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
>
> Can you please split your series up in a saner way? A bunch of the
> patches for drivers with their own subdirectories could be merged ASAP,
> but you bundle them with lots of unrelated bits. Similarly having
> a standalone series for drbd probably makes life easier as you don't
> have to CC random other driver authors on it.
>
> Marco: is there a way to enable the context analysis for parts of
> a directory? I'm not sure that always converting a whole directory
> is going to be feasible in the long run.
Yes, just:
CONTEXT_ANALYSIS_foo.o := y
CONTEXT_ANALYSIS_bar.o := y
...
Alternatively, if most are to be enabled, and only a few holdouts:
CONTEXT_ANALYSIS := y
CONTEXT_ANALYSIS_foo.o := n
CONTEXT_ANALYSIS_bar.o := n
^ permalink raw reply
* Re: [PATCH 20/27] nbd: Enable lock context analysis
From: Nilay Shroff @ 2026-06-10 8:02 UTC (permalink / raw)
To: Bart Van Assche, Jens Axboe
Cc: linux-block, Christoph Hellwig, Marco Elver, Christoph Hellwig,
Josef Bacik
In-Reply-To: <5361809d027e772503ca3cc458aaebdf06792e3b.1781042470.git.bvanassche@acm.org>
On 6/10/26 3:35 AM, Bart Van Assche wrote:
> Add the missing __must_hold() annotations. Enable lock context analysis in
> the Makefile.
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> drivers/block/nbd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index e2fe9e3308fc..345e4b73009d 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -1469,6 +1469,7 @@ static void nbd_config_put(struct nbd_device *nbd)
> }
>
> static int nbd_start_device(struct nbd_device *nbd)
> + __must_hold(&nbd->config_lock)
> {
> struct nbd_config *config = nbd->config;
> int num_connections = config->num_connections;
> @@ -1541,6 +1542,7 @@ static int nbd_start_device(struct nbd_device *nbd)
> }
>
> static int nbd_start_device_ioctl(struct nbd_device *nbd)
> + __must_hold(nbd->config_lock)
> {
> struct nbd_config *config = nbd->config;
> int ret;
> @@ -1592,6 +1594,7 @@ static void nbd_set_cmd_timeout(struct nbd_device *nbd, u64 timeout)
> /* Must be called with config_lock held */
> static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,
> unsigned int cmd, unsigned long arg)
> + __must_hold(nbd->config_lock)
> {
> struct nbd_config *config = nbd->config;
> loff_t bytesize;
>
Above changes are good, however I see nbd also uses @nbd_index_mutex
which guards @nbd_index_idr. So should we also annotate @nbd_index_idr
using __guarded_by(&nbd_index_mutex)?
Thanks,
--Nilay
^ permalink raw reply
* Re: [PATCH v2 00/14] list: Prepare entry iterators to cache cursor state
From: Christian König @ 2026-06-10 8:07 UTC (permalink / raw)
To: Kaitao Cheng, Andy Shevchenko
Cc: Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
Davidlohr Bueso, Paul E . McKenney, Josh Triplett, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Liam Girdwood, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Eddie James, Mark Brown, Maxime Coquelin, Alexandre Torgue,
Laxman Dewangan, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Matthew Auld,
Matthew Brost, Waiman Long, drbd-dev, linux-block,
linux1394-devel, dri-devel, intel-gfx, linux-spi, linux-stm32,
linux-arm-kernel, linux-tegra, linux-sound, linux-kernel,
Andrew Morton, Randy Dunlap, Christian Brauner, David Howells,
Luca Ceresoli, Kaito Cheng, Muchun Song, Philipp Reisner,
Lars Ellenberg, Christoph Böhmwalder, Jens Axboe,
Takashi Sakamoto, Andrzej Hajda, Jaroslav Kysela, Takashi Iwai
In-Reply-To: <5152089a-2808-4fe9-b633-b03018105dd2@linux.dev>
On 6/10/26 08:14, Kaitao Cheng wrote:
> 在 2026/6/9 18:33, Christian König 写道:
>> On 6/9/26 08:13, Kaitao Cheng wrote:
>>> From: Kaito Cheng <chengkaitao@kylinos.cn>
>>>
>>> This series prepares for, and then updates, the list_for_each_entry()
>>> family so the common entry iterators cache their next or previous cursor
>>> before the loop body runs.
>>
>> Why in the world would we want to do that?
>>
>> The safe and non-safe variants have very distinct use cases and that is completely intentional.
>>
>> What we could improve maybe is the documentation, from my experience an astonishing large amount of people have misconceptions about the safe variants.
>>
>>> The first 13 patches open-code loops that intentionally depend on the
>>> old "derive the next entry from the current cursor at the end of the
>>> iteration" behaviour. These loops append work to the list being walked,
>>> restart traversal after dropping a lock, skip an entry consumed by the
>>> current iteration, or otherwise adjust the cursor in the loop body.
>>
>> Well I have to clearly reject the changes for subsystems/components I'm maintaining, that just looks horrible to me and I clearly don't see a good reason for that.
>
> Hi Christian and Andy Shevchenko,
>
> Thanks for taking a look. I would like to clarify the point you raised.
>
> The reason I started looking at this is the original motivation behind
> the _safe() variants. They exist because some users need to remove, move
> or otherwise consume the current entry while walking the list. In that
> case the next cursor has to be preserved before the loop body can modify
> the current entry.
>
> The unfortunate part is that this could not be expressed with the
> existing list_for_each_entry() interface without changing its calling
> convention. The _safe() variants had to grow an extra argument for the
> temporary cursor, and that is why we ended up with a separate family of
> macros.
>
> But conceptually, the distinction does not have to be exposed as two
> different iterator families forever. The difference is an implementation
> detail: whether the iterator keeps the next/previous cursor before the
> body runs. This series makes the common list_for_each_entry() iterators
> do that internally, so the safe and non-safe forms can effectively be
> folded together, or at least the need for a separate public _safe()
> interface becomes much weaker.
>
> There is also a usability issue with the current _safe() interface. The
> caller is forced to define a temporary cursor outside the macro and pass
> it in, even though almost all users never use that cursor directly. It is
> just boilerplate required by the macro implementation. I find that
> redundant and awkward: the temporary cursor is an internal detail of the
> iteration, but every caller has to spell it out.
>
> With the updated list_for_each_entry() implementation, that extra cursor
> can be kept inside the iterator itself. Callers that only want to walk
> the list, including callers that delete or consume the current entry, no
> longer need to carry an otherwise-unused temporary variable just to make
> the macro work.
Well the distinction between list_for_each_entry() and list_for_each_entry_safe() is *not* there because you need an extra variable to hold the next pointer, but because just 'iterating the list' and 'iterating the list while you modify it' are two distinct use cases.
Apart from the technical implications this also has some documentation value for the code using it.
What we could consider with C99 at hand is to have _safe() variants who uses a local hidden variable to hold the next element.
Or maybe come up with a better name instead of _safe() because people seem to misunderstand that quite often.
But mangling the two use cases together just because it is now technical possible is among the worst ideas I've ever heard.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH v2 00/14] list: Prepare entry iterators to cache cursor state
From: Kaitao Cheng @ 2026-06-10 8:18 UTC (permalink / raw)
To: Christian König, Andy Shevchenko
Cc: Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
Davidlohr Bueso, Paul E . McKenney, Josh Triplett, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Liam Girdwood, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Eddie James, Mark Brown, Maxime Coquelin, Alexandre Torgue,
Laxman Dewangan, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Matthew Auld,
Matthew Brost, Waiman Long, drbd-dev, linux-block,
linux1394-devel, dri-devel, intel-gfx, linux-spi, linux-stm32,
linux-arm-kernel, linux-tegra, linux-sound, linux-kernel,
Andrew Morton, Randy Dunlap, Christian Brauner, David Howells,
Luca Ceresoli, Kaito Cheng, Muchun Song, Philipp Reisner,
Lars Ellenberg, Christoph Böhmwalder, Jens Axboe,
Takashi Sakamoto, Andrzej Hajda, Jaroslav Kysela, Takashi Iwai
In-Reply-To: <6b2efdee-95b0-4306-a682-0d0466497ddb@amd.com>
在 2026/6/10 16:07, Christian König 写道:
> On 6/10/26 08:14, Kaitao Cheng wrote:
>> 在 2026/6/9 18:33, Christian König 写道:
>>> On 6/9/26 08:13, Kaitao Cheng wrote:
>>>> From: Kaito Cheng <chengkaitao@kylinos.cn>
>>>>
>>>> This series prepares for, and then updates, the list_for_each_entry()
>>>> family so the common entry iterators cache their next or previous cursor
>>>> before the loop body runs.
>>>
>>> Why in the world would we want to do that?
>>>
>>> The safe and non-safe variants have very distinct use cases and that is completely intentional.
>>>
>>> What we could improve maybe is the documentation, from my experience an astonishing large amount of people have misconceptions about the safe variants.
>>>
>>>> The first 13 patches open-code loops that intentionally depend on the
>>>> old "derive the next entry from the current cursor at the end of the
>>>> iteration" behaviour. These loops append work to the list being walked,
>>>> restart traversal after dropping a lock, skip an entry consumed by the
>>>> current iteration, or otherwise adjust the cursor in the loop body.
>>>
>>> Well I have to clearly reject the changes for subsystems/components I'm maintaining, that just looks horrible to me and I clearly don't see a good reason for that.
>>
>> Hi Christian and Andy Shevchenko,
>>
>> Thanks for taking a look. I would like to clarify the point you raised.
>>
>> The reason I started looking at this is the original motivation behind
>> the _safe() variants. They exist because some users need to remove, move
>> or otherwise consume the current entry while walking the list. In that
>> case the next cursor has to be preserved before the loop body can modify
>> the current entry.
>>
>> The unfortunate part is that this could not be expressed with the
>> existing list_for_each_entry() interface without changing its calling
>> convention. The _safe() variants had to grow an extra argument for the
>> temporary cursor, and that is why we ended up with a separate family of
>> macros.
>>
>> But conceptually, the distinction does not have to be exposed as two
>> different iterator families forever. The difference is an implementation
>> detail: whether the iterator keeps the next/previous cursor before the
>> body runs. This series makes the common list_for_each_entry() iterators
>> do that internally, so the safe and non-safe forms can effectively be
>> folded together, or at least the need for a separate public _safe()
>> interface becomes much weaker.
>>
>> There is also a usability issue with the current _safe() interface. The
>> caller is forced to define a temporary cursor outside the macro and pass
>> it in, even though almost all users never use that cursor directly. It is
>> just boilerplate required by the macro implementation. I find that
>> redundant and awkward: the temporary cursor is an internal detail of the
>> iteration, but every caller has to spell it out.
>>
>> With the updated list_for_each_entry() implementation, that extra cursor
>> can be kept inside the iterator itself. Callers that only want to walk
>> the list, including callers that delete or consume the current entry, no
>> longer need to carry an otherwise-unused temporary variable just to make
>> the macro work.
>
> Well the distinction between list_for_each_entry() and list_for_each_entry_safe() is *not* there because you need an extra variable to hold the next pointer, but because just 'iterating the list' and 'iterating the list while you modify it' are two distinct use cases.
>
> Apart from the technical implications this also has some documentation value for the code using it.
>
> What we could consider with C99 at hand is to have _safe() variants who uses a local hidden variable to hold the next element.
>
> Or maybe come up with a better name instead of _safe() because people seem to misunderstand that quite often.
>
> But mangling the two use cases together just because it is now technical possible is among the worst ideas I've ever heard.
>
Should we revert to v1, or keep list_for_each_entry() and
list_for_each_entry_safe() as they are, close this thread, and make no
changes?
Link to v1:
https://lore.kernel.org/all/20260529082149.76764-1-kaitao.cheng@linux.dev/
Or do you have any better suggestions?
--
Thanks
Kaitao Cheng
^ permalink raw reply
* Re: [PATCH v2 01/83] block: rust: fix `Send` bound for `GenDisk`
From: Andreas Hindborg @ 2026-06-10 9:00 UTC (permalink / raw)
To: Yuan Tan
Cc: Liam R. Howlett, Alice Ryhl, Anna-Maria Behnsen, Benno Lossin,
Björn Roy Baron, Boqun Feng, Danilo Krummrich,
FUJITA Tomonori, Frederic Weisbecker, Gary Guo, Jens Axboe,
John Stultz, Lorenzo Stoakes, Lyude Paul, Miguel Ojeda,
Stephen Boyd, Thomas Gleixner, Trevor Gross, linux-block,
linux-kernel, linux-mm, rust-for-linux, Priya Bala Govindasamy,
Dylan Zueck, Yuan Tan
In-Reply-To: <CABrc2FU9HuRp4tVEU_R1RdMMRkkS=tM4Uv70WG3UBTeho_C42Q@mail.gmail.com>
Yuan Tan <ytan089@ucr.edu> writes:
> On Tue, Jun 9, 2026 at 12:13 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> The `Send` implementation for `GenDisk<T>` was conditioned on `T: Send`.
>> This constrains the wrong type. `T` is the `Operations` implementation,
>> which is typically a zero-sized marker type that carries no data, so `T:
>> Send` says nothing about whether the data a `GenDisk` actually owns can be
>> moved to another thread.
>>
>> A `GenDisk<T>` owns the queue data `T::QueueData` (stored as the
>> `gendisk`'s `queuedata` and dropped when the `GenDisk` is dropped) and an
>> `Arc<TagSet<T>>`. These are the values transferred when a `GenDisk` is sent
>> across a thread boundary, so the `Send` bound must constrain exactly them.
>> Bound `T::QueueData: Send` and `Arc<TagSet<T>>: Send` instead.
>>
>> Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
>> Suggested-by: Yuan Tan <ytan089@ucr.edu>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>>
>> Please take patch from Yuan instead of this one, if they send a fixed
>> version [1].
>>
>> [1] https://lore.kernel.org/r/8839ddc5ff54bf454d508cde91d27d00fc3e2dd8.1780633578.git.ytan089@ucr.edu
>
> My last email mistakenly enabled html. So I am here to resend it. Hope
> it doesn't disturb anyone.
>
> Sorry, I've been busy with other things and haven't had the chance to
> send the fixed version.
>
> Thank you very much for reviewing the patch and for preparing the v2 version.
>
> Could you please add the following when applying this patch?
> Reported-by: Priya Bala Govindasamy <pgovind2@uci.edu>
> Reported-by: Dylan Zueck <dzueck@uci.edu>
>
> I didn't discover this issue myself. I just helped write the patch and
> I don't want them to lose their credit for it.
>
> Please let me know if you would prefer that I send a v3 instead.
I would absolutely encourage you to send a v3 so we can pick that one.
Your emails are not arriving in my inbox though. I only see this one on
the list. Please check your setup for outgoing email.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2 00/14] list: Prepare entry iterators to cache cursor state
From: Christian König @ 2026-06-10 9:11 UTC (permalink / raw)
To: Kaitao Cheng, Andy Shevchenko
Cc: Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
Davidlohr Bueso, Paul E . McKenney, Josh Triplett, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Liam Girdwood, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Eddie James, Mark Brown, Maxime Coquelin, Alexandre Torgue,
Laxman Dewangan, Neil Armstrong, Robert Foss, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Matthew Auld,
Matthew Brost, Waiman Long, drbd-dev, linux-block,
linux1394-devel, dri-devel, intel-gfx, linux-spi, linux-stm32,
linux-arm-kernel, linux-tegra, linux-sound, linux-kernel,
Andrew Morton, Randy Dunlap, Christian Brauner, David Howells,
Luca Ceresoli, Kaito Cheng, Muchun Song, Philipp Reisner,
Lars Ellenberg, Christoph Böhmwalder, Jens Axboe,
Takashi Sakamoto, Andrzej Hajda, Jaroslav Kysela, Takashi Iwai
In-Reply-To: <2399841f-d834-4652-8285-4a15c7d9a9b9@linux.dev>
On 6/10/26 10:18, Kaitao Cheng wrote:
>
>
> 在 2026/6/10 16:07, Christian König 写道:
>> On 6/10/26 08:14, Kaitao Cheng wrote:
>>> 在 2026/6/9 18:33, Christian König 写道:
>>>> On 6/9/26 08:13, Kaitao Cheng wrote:
>>>>> From: Kaito Cheng <chengkaitao@kylinos.cn>
>>>>>
>>>>> This series prepares for, and then updates, the list_for_each_entry()
>>>>> family so the common entry iterators cache their next or previous cursor
>>>>> before the loop body runs.
>>>>
>>>> Why in the world would we want to do that?
>>>>
>>>> The safe and non-safe variants have very distinct use cases and that is completely intentional.
>>>>
>>>> What we could improve maybe is the documentation, from my experience an astonishing large amount of people have misconceptions about the safe variants.
>>>>
>>>>> The first 13 patches open-code loops that intentionally depend on the
>>>>> old "derive the next entry from the current cursor at the end of the
>>>>> iteration" behaviour. These loops append work to the list being walked,
>>>>> restart traversal after dropping a lock, skip an entry consumed by the
>>>>> current iteration, or otherwise adjust the cursor in the loop body.
>>>>
>>>> Well I have to clearly reject the changes for subsystems/components I'm maintaining, that just looks horrible to me and I clearly don't see a good reason for that.
>>>
>>> Hi Christian and Andy Shevchenko,
>>>
>>> Thanks for taking a look. I would like to clarify the point you raised.
>>>
>>> The reason I started looking at this is the original motivation behind
>>> the _safe() variants. They exist because some users need to remove, move
>>> or otherwise consume the current entry while walking the list. In that
>>> case the next cursor has to be preserved before the loop body can modify
>>> the current entry.
>>>
>>> The unfortunate part is that this could not be expressed with the
>>> existing list_for_each_entry() interface without changing its calling
>>> convention. The _safe() variants had to grow an extra argument for the
>>> temporary cursor, and that is why we ended up with a separate family of
>>> macros.
>>>
>>> But conceptually, the distinction does not have to be exposed as two
>>> different iterator families forever. The difference is an implementation
>>> detail: whether the iterator keeps the next/previous cursor before the
>>> body runs. This series makes the common list_for_each_entry() iterators
>>> do that internally, so the safe and non-safe forms can effectively be
>>> folded together, or at least the need for a separate public _safe()
>>> interface becomes much weaker.
>>>
>>> There is also a usability issue with the current _safe() interface. The
>>> caller is forced to define a temporary cursor outside the macro and pass
>>> it in, even though almost all users never use that cursor directly. It is
>>> just boilerplate required by the macro implementation. I find that
>>> redundant and awkward: the temporary cursor is an internal detail of the
>>> iteration, but every caller has to spell it out.
>>>
>>> With the updated list_for_each_entry() implementation, that extra cursor
>>> can be kept inside the iterator itself. Callers that only want to walk
>>> the list, including callers that delete or consume the current entry, no
>>> longer need to carry an otherwise-unused temporary variable just to make
>>> the macro work.
>>
>> Well the distinction between list_for_each_entry() and list_for_each_entry_safe() is *not* there because you need an extra variable to hold the next pointer, but because just 'iterating the list' and 'iterating the list while you modify it' are two distinct use cases.
>>
>> Apart from the technical implications this also has some documentation value for the code using it.
>>
>> What we could consider with C99 at hand is to have _safe() variants who uses a local hidden variable to hold the next element.
>>
>> Or maybe come up with a better name instead of _safe() because people seem to misunderstand that quite often.
>>
>> But mangling the two use cases together just because it is now technical possible is among the worst ideas I've ever heard.
>>
>
> Should we revert to v1, or keep list_for_each_entry() and
> list_for_each_entry_safe() as they are, close this thread, and make no
> changes?
>
> Link to v1:
> https://lore.kernel.org/all/20260529082149.76764-1-kaitao.cheng@linux.dev/
>
> Or do you have any better suggestions?
v1 looks perfectly reasonable to me.
You should just include some patches in the same patch set to actually use the new macros.
If you modify the files under drivers/dma-buf or drivers/gpu/drm/amd to use the new macro I'm happy to review that.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH v2] rust: add procedural macro for declaring configfs attributes
From: Malte Wechter @ 2026-06-10 9:15 UTC (permalink / raw)
To: Gary Guo, Andreas Hindborg, Breno Leitao, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Jens Axboe
Cc: linux-kernel, rust-for-linux, linux-block
In-Reply-To: <DIZHKJSZXQ4Z.6SPXJVGDV9ZW@garyguo.net>
On 6/3/26 4:32 PM, Gary Guo wrote:
> On Wed Jun 3, 2026 at 3:08 PM BST, Malte Wechter wrote:
>> Implement `configfs_attrs!` as a procedural macro using `syn`, this
>> improves readability and maintainability. Remove the old macro and
>> replace all uses with the new macro. Add the new macro implementation
>> file to MAINTAINERS.
>>
>> Signed-off-by: Malte Wechter <maltewechter@gmail.com>
>> ---
>> Changes in v2:
>> - Add a try_parse helper function to macros/helpers.rs
>> - Fix bug where 'child' configuration gets dropped if trailing comma is missing (sashiko)
>> - Link to v1: https://lore.kernel.org/r/20260520-configfs-syn-v1-1-6c5b80a9cef2@gmail.com
>> ---
>> MAINTAINERS | 1 +
>> drivers/block/rnull/configfs.rs | 2 +-
>> rust/kernel/configfs.rs | 251 ----------------------------------------
>> rust/macros/configfs_attrs.rs | 182 +++++++++++++++++++++++++++++
>> rust/macros/helpers.rs | 15 +++
>> rust/macros/lib.rs | 85 ++++++++++++++
>> samples/rust/rust_configfs.rs | 2 +-
>> 7 files changed, 285 insertions(+), 253 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 2fb1c75afd163..45f7a1ec93b45 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6464,6 +6464,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git config
>> F: fs/configfs/
>> F: include/linux/configfs.h
>> F: rust/kernel/configfs.rs
>> +F: rust/macros/configfs_attrs.rs
>> F: samples/configfs/
>> F: samples/rust/rust_configfs.rs
>>
>> diff --git a/drivers/block/rnull/configfs.rs b/drivers/block/rnull/configfs.rs
>> index 7c2eb5c0b7228..f28ec69d79846 100644
>> --- a/drivers/block/rnull/configfs.rs
>> +++ b/drivers/block/rnull/configfs.rs
>> @@ -4,8 +4,8 @@
>> use kernel::{
>> block::mq::gen_disk::{GenDisk, GenDiskBuilder},
>> configfs::{self, AttributeOperations},
>> - configfs_attrs,
>> fmt::{self, Write as _},
>> + macros::configfs_attrs,
>> new_mutex,
>> page::PAGE_SIZE,
>> prelude::*,
>> diff --git a/rust/macros/configfs_attrs.rs b/rust/macros/configfs_attrs.rs
>> new file mode 100644
>> index 0000000000000..a7fc75cdebcc0
>> --- /dev/null
>> +++ b/rust/macros/configfs_attrs.rs
>> @@ -0,0 +1,182 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +use quote::{
>> + quote, //
>> + ToTokens,
>> +};
>> +
>> +use proc_macro2::{
>> + Span, //
>> +};
>> +
>> +use syn::{
>> + bracketed,
>> + parse::{
>> + Parse,
>> + ParseStream, //
>> + },
>> + punctuated::Punctuated,
>> + spanned::Spanned,
>> + Ident,
>> + LitInt,
>> + Token,
>> + Type, //
>> +};
>> +
>> +use crate::helpers::try_parse;
>> +
>> +pub(crate) struct ConfigfsAttrs {
>> + container: Type,
>> + data: Type,
>> + child: Option<Type>,
>> + attributes: Vec<(Ident, LitInt)>,
>> +}
>> +
>> +fn parse_attribute_field(stream: ParseStream<'_>) -> syn::Result<(Ident, LitInt)> {
>> + let id = stream.parse::<syn::Ident>()?;
>> + let _colon = stream.parse::<Token![:]>()?;
>> + let v = stream.parse::<LitInt>()?;
>> + Ok((id, v))
>> +}
>> +
>> +fn parse_named_field(stream: ParseStream<'_>, name: &str) -> syn::Result<Type> {
>> + let name_id = stream.parse::<Ident>()?;
>> + if name_id != name {
>> + return Err(parse_field_error(name_id.span(), &name_id, name));
>> + }
>> + let _colon = stream.parse::<Token![:]>()?;
>> + let v = stream.parse::<Type>()?;
>> + stream.parse::<Token![,]>()?;
>> + Ok(v)
>> +}
>> +
>> +fn parse_attributes(stream: ParseStream<'_>) -> syn::Result<Vec<(Ident, LitInt)>> {
>> + let attribute_id = stream.parse::<Ident>()?;
>> + if attribute_id != "attributes" {
>> + return Err(syn::Error::new(
>> + attribute_id.span(),
>> + format!(
>> + "unexpected identifier: {}, expected: 'attributes'",
>> + attribute_id
>> + ),
>> + ));
>> + }
>> + stream.parse::<Token![:]>()?;
>> + let attr_stream;
>> + let _bracket = bracketed!(attr_stream in stream);
>> + let attributes = Punctuated::<(Ident, LitInt), Token![,]>::parse_terminated_with(
>> + &attr_stream,
>> + parse_attribute_field,
>> + )?;
>> + let attributes = attributes.into_iter().collect::<Vec<_>>();
>> +
>> + stream.parse::<Option<Token![,]>>()?;
>> + Ok(attributes)
>> +}
>> +
>> +fn parse_field_error(span: Span, name: &Ident, expected_name: &str) -> syn::Error {
>> + syn::Error::new(
>> + span,
>> + format!("Unexpected field name, got: {name} expected: {expected_name}"),
>> + )
>> +}
>> +
>> +impl Parse for ConfigfsAttrs {
>> + fn parse(input: ParseStream<'_>) -> syn::Result<Self> {
>> + let container = try_parse(input, |s| parse_named_field(s, "container"))?;
>> + let data = try_parse(input, |s| parse_named_field(s, "data"))?;
>> + let child = try_parse(input, |s| parse_named_field(s, "child")).ok();
>> + let attributes = parse_attributes(input)?;
> I have a `parse_ordered_fields!()` macro in module.rs, please extract it to
> helpers and use it instead of implementing the parsing in an ad-hoc manner.
That is a good idea.
>> +
>> + Ok(ConfigfsAttrs {
>> + container,
>> + data,
>> + child,
>> + attributes,
>> + })
>> + }
>> +}
>> +
>> +fn make_static_ident<T: ToTokens>(ty: &T, suffix: &str) -> syn::Ident {
>> + let raw_id = quote! { #ty }.to_string();
>> +
>> + // Sanitizing syn::Type::Path, this is safe since it is
>> + // only used as the identifier.
>> + let normalized = raw_id
>> + .split("::")
>> + .map(|s| String::from(s.trim()))
>> + .reduce(|a, b| format!("{a}_{b}"))
>> + .expect("Cannot be empty")
>> + .to_uppercase()
>> + .replace(|c: char| !c.is_alphanumeric(), "_");
>> +
>> + Ident::new(&format!("{}_{}", normalized, suffix), ty.span())
>> +}
>> +
>> +pub(crate) fn configfs_attrs(cfs_attrs: ConfigfsAttrs) -> proc_macro2::TokenStream {
>> + let (container_ty, data_ty) = (&cfs_attrs.container, &cfs_attrs.data);
>> +
>> + let data_tp_ident = make_static_ident(data_ty, "TPE");
>> + let data_attr_ident = make_static_ident(data_ty, "ATTR_LIST");
> Instead of creating identifers like this, just scope them properly so that
> a fixed identifier is used without colliding.
I believe it is nice to keep the identifiers unique, especially if you
have many fields
you can easily differentiate them.
>> +
>> + let n = cfs_attrs.attributes.len() + 1;
>> +
>> + let attr_list = quote! {
>> + static #data_attr_ident: kernel::configfs::AttributeList<#n, #data_ty> =
>> + // SAFETY: We are expanding `configfs_attrs`.
>> + unsafe { kernel::configfs::AttributeList::new() };
>> + };
>> +
>> + let mut attrs = Vec::new();
>> + for (attr_idx, (name, id)) in cfs_attrs.attributes.iter().enumerate() {
>> + let name_with_attr = make_static_ident(name, "ATTR");
>> +
>> + let id: u64 = match id.base10_parse::<u64>() {
>> + Ok(v) => v,
>> + Err(_) => {
>> + return syn::Error::new(id.span(), "Could not parse attribute ID as a u64")
>> + .to_compile_error();
>> + }
>> + };
> Why parsing? The ID looks like it's just substituted as is.
For correctness, if you pass a negative integer literal it will panic
without this parsing.
This is not likely, but it provides a nice error message if this were to happen.
I can maybe move it to the parsing logic instead.
>
> Best,
> Gary
>
>> +
>> + attrs.push(quote! {
>> + static #name_with_attr: kernel::configfs::Attribute<#id, #data_ty, #data_ty> =
>> + // SAFETY: We are expanding `configfs_attrs`.
>> + unsafe {
>> + kernel::configfs::Attribute::new(kernel::c_str!(::core::stringify!(#name)))
>> + };
>> +
>> + // SAFETY: By design of this macro, the name of the variable we
>> + // invoke the `add` method on below, is not visible outside of
>> + // the macro expansion. The macro does not operate concurrently
>> + // on this variable, and thus we have exclusive access to the
>> + // variable.
>> + unsafe { #data_attr_ident.add::<#attr_idx, #id, _>(&#name_with_attr) }
>> + });
>> + }
>> +
>> + let has_child_code = if let Some(child) = cfs_attrs.child {
>> + quote! { new_with_child_ctor::<#n, #child>}
>> + } else {
>> + quote! { new::<#n> }
>> + };
>> +
>> + let data_type = quote! {
>> + {
>> + static #data_tp_ident:
>> + kernel::configfs::ItemType<#container_ty, #data_ty> =
>> + kernel::configfs::ItemType::<#container_ty, #data_ty>::#has_child_code(
>> + &THIS_MODULE, &#data_attr_ident
>> + );
>> + &#data_tp_ident
>> + }
>> + };
>> +
>> + quote! {
>> + {
>> + #attr_list
>> + #(#attrs)*
>> + #data_type
>> + }
>> + }
>> +}
>> diff --git a/rust/macros/helpers.rs b/rust/macros/helpers.rs
>> index d18fbf4daa0a5..fdab8804e1ba9 100644
>> --- a/rust/macros/helpers.rs
>> +++ b/rust/macros/helpers.rs
>> @@ -4,6 +4,7 @@
>> use quote::ToTokens;
>> use syn::{
>> parse::{
>> + discouraged::Speculative,
>> Parse,
>> ParseStream, //
>> },
>> @@ -54,6 +55,20 @@ pub(crate) fn file() -> String {
>> }
>> }
>>
>> +pub(crate) fn try_parse<T>(
>> + input: ParseStream<'_>,
>> + parser: impl FnOnce(ParseStream<'_>) -> Result<T>,
>> +) -> Result<T> {
>> + let fork = input.fork();
>> + match parser(&fork) {
>> + Ok(value) => {
>> + input.advance_to(&fork);
>> + Ok(value)
>> + }
>> + Err(e) => Err(e),
>> + }
>> +}
>> +
>> /// Obtain all `#[cfg]` attributes.
>> pub(crate) fn gather_cfg_attrs(attr: &[Attribute]) -> impl Iterator<Item = &Attribute> + '_ {
>> attr.iter().filter(|a| a.path().is_ident("cfg"))
>> diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
>> index 2cfd59e0f9e7c..745ba83c828b9 100644
>> --- a/rust/macros/lib.rs
>> +++ b/rust/macros/lib.rs
>> @@ -15,6 +15,8 @@
>> #![cfg_attr(not(CONFIG_RUSTC_HAS_SPAN_FILE), feature(proc_macro_span))]
>>
>> mod concat_idents;
>> +#[cfg(CONFIG_CONFIGFS_FS)]
>> +mod configfs_attrs;
>> mod export;
>> mod fmt;
>> mod helpers;
>> @@ -489,3 +491,86 @@ pub fn kunit_tests(attr: TokenStream, input: TokenStream) -> TokenStream {
>> .unwrap_or_else(|e| e.into_compile_error())
>> .into()
>> }
>> +
>> +/// Define a list of configfs attributes statically.
>> +///
>> +/// # Examples
>> +///
>> +/// ```ignore
>> +/// let item_type = configfs_attrs! {
>> +/// container: configfs::Subsystem<Configuration>,
>> +/// data: Configuration,
>> +/// child: Child,
>> +/// attributes: [
>> +/// message: 0,
>> +/// bar: 1,
>> +/// ],
>> +/// };
>> +///```
>> +///
>> +/// Expands the following output:
>> +/// let item_type = {
>> +/// static CONFIGURATION_ATTR_LIST: kernel::configfs::AttributeList<
>> +/// 3usize,
>> +/// Configuration,
>> +/// > = unsafe { kernel::configfs::AttributeList::new() };
>> +/// static MESSAGE_ATTR: kernel::configfs::Attribute<
>> +/// 0u64,
>> +/// Configuration,
>> +/// Configuration,
>> +/// > = unsafe {
>> +/// kernel::configfs::Attribute::new({
>> +/// const S: &str = "message\u{0}";
>> +/// const C: &kernel::str::CStr = match kernel::str::CStr::from_bytes_with_nul(
>> +/// S.as_bytes(),
>> +/// ) {
>> +/// Ok(v) => v,
>> +/// Err(_) => {
>> +/// ::core::panicking::panic_fmt(
>> +/// format_args!("string contains interior NUL"),
>> +/// );
>> +/// }
>> +/// };
>> +/// C
>> +/// })
>> +/// };
>> +/// unsafe { CONFIGURATION_ATTR_LIST.add::<0usize, 0u64, _>(&MESSAGE_ATTR) }
>> +/// static BAR_ATTR: kernel::configfs::Attribute<
>> +/// 1u64,
>> +/// Configuration,
>> +/// Configuration,
>> +/// > = unsafe {
>> +/// kernel::configfs::Attribute::new({
>> +/// const S: &str = "bar\u{0}";
>> +/// const C: &kernel::str::CStr = match kernel::str::CStr::from_bytes_with_nul(
>> +/// S.as_bytes(),
>> +/// ) {
>> +/// Ok(v) => v,
>> +/// Err(_) => {
>> +/// ::core::panicking::panic_fmt(
>> +/// format_args!("string contains interior NUL"),
>> +/// );
>> +/// }
>> +/// };
>> +/// C
>> +/// })
>> +/// };
>> +/// unsafe { CONFIGURATION_ATTR_LIST.add::<1usize, 1u64, _>(&BAR_ATTR) }
>> +/// {
>> +/// static CONFIGURATION_TPE: kernel::configfs::ItemType<
>> +/// Subsystem<Configuration>,
>> +/// Configuration,
>> +/// > = kernel::configfs::ItemType::<
>> +/// Subsystem<Configuration>,
>> +/// Configuration,
>> +/// >::new_with_child_ctor::<3usize, Child>(&THIS_MODULE, &CONFIGURATION_ATTR_LIST);
>> +/// &CONFIGURATION_TPE
>> +/// }
>> +/// };
>> +///
>> +#[cfg(CONFIG_CONFIGFS_FS)]
>> +#[proc_macro]
>> +pub fn configfs_attrs(input: TokenStream) -> TokenStream {
>> + configfs_attrs::configfs_attrs(parse_macro_input!(input as configfs_attrs::ConfigfsAttrs))
>> + .into()
>> +}
>> diff --git a/samples/rust/rust_configfs.rs b/samples/rust/rust_configfs.rs
>> index a1bd9db6010da..876462f7789d1 100644
>> --- a/samples/rust/rust_configfs.rs
>> +++ b/samples/rust/rust_configfs.rs
>> @@ -4,7 +4,7 @@
>>
>> use kernel::alloc::flags;
>> use kernel::configfs;
>> -use kernel::configfs::configfs_attrs;
>> +use kernel::macros::configfs_attrs;
>> use kernel::new_mutex;
>> use kernel::page::PAGE_SIZE;
>> use kernel::prelude::*;
>>
>> ---
>> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
>> change-id: 20260417-configfs-syn-191e07130027
>>
>> Best regards,
Best regards
>
^ permalink raw reply
* Re: [PATCH 18/27] loop: Add lock context annotations
From: Nilay Shroff @ 2026-06-10 9:21 UTC (permalink / raw)
To: Bart Van Assche, Jens Axboe
Cc: linux-block, Christoph Hellwig, Marco Elver, Nathan Chancellor
In-Reply-To: <1391f73ea3af981cd2e76b56cdfe47b5bb56ffa0.1781042470.git.bvanassche@acm.org>
On 6/10/26 3:35 AM, Bart Van Assche wrote:
> Add lock context annotations that are compatible with Clang.
>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> drivers/block/loop.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 1a33536000e0..ff7eff102c5a 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -106,6 +106,8 @@ static DEFINE_MUTEX(loop_validate_mutex);
> * loop_configure()/loop_change_fd()/__loop_clr_fd() calls.
> */
> static int loop_global_lock_killable(struct loop_device *lo)
> + __cond_acquires(0, &loop_validate_mutex)
> + __cond_acquires(0, &lo->lo_mutex)
> {
> int err;
>
> @@ -124,6 +126,8 @@ static int loop_global_lock_killable(struct loop_device *lo)
> * @lo: struct loop_device
> */
> static void loop_global_unlock(struct loop_device *lo)
> + __releases(&lo->lo_mutex)
> + __releases(&loop_validate_mutex)
> {
> mutex_unlock(&lo->lo_mutex);
> mutex_unlock(&loop_validate_mutex);
>
This looks good to me.
One thing I noticed while looking through the loop driver is that it also defines
@loop_ctl_mutex, which protects @loop_index_idr. It might be worth annotating
@loop_index_idr with `__guarded_by(&loop_ctl_mutex) as well so that Clang can
validate accesses to the IDR against the corresponding locking requirements.
Thanks,
--Nilay
^ permalink raw reply
* Re: [PATCH] rust: block: require `Sync` for `Operations::QueueData`
From: Gary Guo @ 2026-06-10 10:01 UTC (permalink / raw)
To: Andreas Hindborg, Boqun Feng, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Jens Axboe, Daniel Almeida
Cc: linux-block, rust-for-linux, linux-kernel
In-Reply-To: <20260608-queue-data-sync-v1-1-0efff051aaf3@kernel.org>
On Mon Jun 8, 2026 at 9:24 AM BST, Andreas Hindborg wrote:
> The queue data installed in a `GenDisk` is stored in the request queue and
> handed back to the driver as a shared borrow through the `queue_rq` and
> `commit_rqs` callbacks. Both callbacks obtain that borrow via
> `ForeignOwnable::borrow` and may execute concurrently on several CPUs,
> since the block layer runs one hardware queue per CPU. That means a shared
> reference to the same queue data can be live on multiple threads at once,
> which is only sound when the referent is `Sync`.
>
> The initial `GenDisk` private data support omitted this bound, so a
> driver could install a non-`Sync` type as queue data and then access
> it concurrently from multiple CPUs without synchronization. Add a
> `Sync` bound to the `QueueData` associated type to rule that out.
>
> Fixes: 90d952fac8ac ("rust: block: add `GenDisk` private data support")
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/kernel/block/mq/operations.rs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v2] rust: add procedural macro for declaring configfs attributes
From: Gary Guo @ 2026-06-10 10:05 UTC (permalink / raw)
To: Malte Wechter, Gary Guo, Andreas Hindborg, Breno Leitao,
Miguel Ojeda, Boqun Feng, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Jens Axboe
Cc: linux-kernel, rust-for-linux, linux-block
In-Reply-To: <f6a513e8-227f-4b22-bd4d-81d88536eff1@gmail.com>
On Wed Jun 10, 2026 at 10:15 AM BST, Malte Wechter wrote:
>>> +
>>> + Ok(ConfigfsAttrs {
>>> + container,
>>> + data,
>>> + child,
>>> + attributes,
>>> + })
>>> + }
>>> +}
>>> +
>>> +fn make_static_ident<T: ToTokens>(ty: &T, suffix: &str) -> syn::Ident {
>>> + let raw_id = quote! { #ty }.to_string();
>>> +
>>> + // Sanitizing syn::Type::Path, this is safe since it is
>>> + // only used as the identifier.
>>> + let normalized = raw_id
>>> + .split("::")
>>> + .map(|s| String::from(s.trim()))
>>> + .reduce(|a, b| format!("{a}_{b}"))
>>> + .expect("Cannot be empty")
>>> + .to_uppercase()
>>> + .replace(|c: char| !c.is_alphanumeric(), "_");
>>> +
>>> + Ident::new(&format!("{}_{}", normalized, suffix), ty.span())
>>> +}
>>> +
>>> +pub(crate) fn configfs_attrs(cfs_attrs: ConfigfsAttrs) -> proc_macro2::TokenStream {
>>> + let (container_ty, data_ty) = (&cfs_attrs.container, &cfs_attrs.data);
>>> +
>>> + let data_tp_ident = make_static_ident(data_ty, "TPE");
>>> + let data_attr_ident = make_static_ident(data_ty, "ATTR_LIST");
>> Instead of creating identifers like this, just scope them properly so that
>> a fixed identifier is used without colliding.
>
> I believe it is nice to keep the identifiers unique, especially if you
> have many fields
> you can easily differentiate them.
What make_static_ident is doing I think is quite hacky. I'd rather not having
them. Plus, the identifiers are not seen by users anyway.
Best,
Gary
^ permalink raw reply
* Re: [PATCH v1] floppy: Drop unused pnp driver data
From: Denis Efremov (Oracle) @ 2026-06-10 10:59 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Jens Axboe
Cc: linux-block, linux-kernel
In-Reply-To: <99dbf851ffb99229ea1dcfd8f58e9ee6a1f05349.1781075967.git.u.kleine-koenig@baylibre.com>
On 10/06/2026 11:27, Uwe Kleine-König (The Capable Hub) wrote:
> The pnp_device_id array is only used for module data to support
> auto-loading the floppy module. So the .driver_data member is unused and
> this assignment can be dropped.
>
> While touching that array, align the coding style to what is used most
> for these.
>
> This patch doesn't modify the compiled array, only its representation
> in source form benefits. The former was confirmed with x86 and arm64
> builds.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Denis Efremov (Oracle) <efremov@linux.com>
> ---
> Hello,
>
> I intend to change struct pnp_device_id and for that it's required that
> .driver_data is not assigned using a list initializer. Instead of
> converting it to a named initializer, drop the assignment as the value
> is unused. So this is both a cleanup and a preparation for a later patch
> series.
>
> See
> https://lore.kernel.org/all/cover.1779878004.git.u.kleine-koenig@baylibre.com/
> for a more verbose description on the mentioned change to struct
> pnp_device_id (though this is about platform_device_id, but the idea
> here is the same).
>
> Best regards
> Uwe
>
> drivers/block/floppy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index 0509746f8aed..dca495be0683 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -5012,8 +5012,8 @@ MODULE_LICENSE("GPL");
>
> /* This doesn't actually get used other than for module information */
> static const struct pnp_device_id floppy_pnpids[] = {
> - {"PNP0700", 0},
> - {}
> + { .id = "PNP0700" },
> + { }
> };
>
> MODULE_DEVICE_TABLE(pnp, floppy_pnpids);
>
> base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
^ permalink raw reply
* Re: [PATCH 00/27] Enable lock context analysis in drivers/block/
From: Christoph Hellwig @ 2026-06-10 11:30 UTC (permalink / raw)
To: Marco Elver; +Cc: Christoph Hellwig, Bart Van Assche, Jens Axboe, linux-block
In-Reply-To: <CANpmjNORsF2oExcOphnGgnTt3hJEWP0tB6zua0sTG=n7gJbEZA@mail.gmail.com>
Cool, thanks!
Bart: maytbe for next version just enable it on a per-driver basis.
Once all are covered we can switch to directory-wide.
^ permalink raw reply
* Re: [PATCH v1] floppy: Drop unused pnp driver data
From: Jens Axboe @ 2026-06-10 12:28 UTC (permalink / raw)
To: Denis Efremov, Uwe Kleine-König (The Capable Hub)
Cc: linux-block, linux-kernel
In-Reply-To: <99dbf851ffb99229ea1dcfd8f58e9ee6a1f05349.1781075967.git.u.kleine-koenig@baylibre.com>
On Wed, 10 Jun 2026 09:27:55 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> The pnp_device_id array is only used for module data to support
> auto-loading the floppy module. So the .driver_data member is unused and
> this assignment can be dropped.
>
> While touching that array, align the coding style to what is used most
> for these.
>
> [...]
Applied, thanks!
[1/1] floppy: Drop unused pnp driver data
commit: 64e335790272d9b0468af3a70e34f377924b156f
Best regards,
--
Jens Axboe
^ 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