* Re: [PATCH V4 6/9] null_blk: clean up null_del_dev() to use cached dev pointer
From: Nilay Shroff @ 2026-07-10 13:03 UTC (permalink / raw)
To: Zizhi Wo, axboe, dlemoal, kch, johannes.thumshirn, kbusch,
bvanassche, linux-block
Cc: linux-kernel, yangerkun, chengzhihao1, wozizhi
In-Reply-To: <20260709100452.3520482-7-wozizhi@huaweicloud.com>
On 7/9/26 3:34 PM, Zizhi Wo wrote:
> Replace remaining nullb->dev dereferences with the already-cached
> local dev variable. No functional change.
>
> Signed-off-by: Zizhi Wo<wozizhi@huawei.com>
Looks good to me.
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH 2/2] module: Bring includes in linux/kmod.h up to date
From: Aaron Tomlin @ 2026-07-10 13:57 UTC (permalink / raw)
To: Petr Pavlu
Cc: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Pavel Machek, Len Brown, Andrew Morton, Danilo Krummrich,
Nikolay Aleksandrov, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Howells,
Jarkko Sakkinen, Paul Moore, James Morris, Serge E. Hallyn,
Kentaro Takeda, Tetsuo Handa, linux-edac, linux-kernel, drbd-dev,
linux-block, greybus-dev, linuxppc-dev, linux-acpi, linux-fbdev,
dri-devel, linux-fsdevel, linux-nfs, ocfs2-devel, cgroups,
linux-modules, linux-pm, driver-core, bridge, netdev, keyrings,
linux-security-module
In-Reply-To: <20260708154510.6794-3-petr.pavlu@suse.com>
On Wed, Jul 08, 2026 at 05:44:30PM +0200, Petr Pavlu wrote:
> Including linux/kmod.h alone results in 1.5 MB of preprocessed output, even
> though it provides only a few functions and macros.
>
> The header currently depends on:
>
> * __printf() -> linux/compiler_attributes.h,
> * ENOSYS -> linux/errno.h,
> * bool -> linux/types.h.
>
> Include only these files, reducing the preprocessed output to 10 kB.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> include/linux/kmod.h | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> index 9a07c3215389..b9474a62a568 100644
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -2,17 +2,9 @@
> #ifndef __LINUX_KMOD_H__
> #define __LINUX_KMOD_H__
>
> -/*
> - * include/linux/kmod.h
> - */
> -
> -#include <linux/umh.h>
> -#include <linux/gfp.h>
> -#include <linux/stddef.h>
> +#include <linux/compiler_attributes.h>
> #include <linux/errno.h>
> -#include <linux/compiler.h>
> -#include <linux/workqueue.h>
> -#include <linux/sysctl.h>
> +#include <linux/types.h>
>
> #ifdef CONFIG_MODULES
> /* modprobe exit status on success, -ve on error. Return value
> --
> 2.54.0
>
LGTM. Thank you.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH V4 5/9] null_blk: free zones array on device power-off
From: Nilay Shroff @ 2026-07-10 14:24 UTC (permalink / raw)
To: Zizhi Wo, axboe, dlemoal, kch, johannes.thumshirn, kbusch,
bvanassche, linux-block
Cc: linux-kernel, yangerkun, chengzhihao1, wozizhi
In-Reply-To: <20260709100452.3520482-6-wozizhi@huaweicloud.com>
On 7/9/26 3:34 PM, Zizhi Wo wrote:
> null_init_zoned_dev() allocates dev->zones when a zoned device is powered
> on, but null_del_dev() never frees it on power-off; dev->zones is only
> freed later in null_free_dev(), when the configfs directory is removed. If
> the device is powered off and then on again, null_init_zoned_dev()
> allocates a new array and overwrites the dev->zones pointer, leaking the
> previous allocation each power cycle.
>
> Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it.
> And calling null_del_dev() in null_free_dev() is no longer necessary
> because every caller already invokes null_del_dev() first: via
> nullb_group_drop_item() before nullb_device_release(), in the
> null_add_dev() error path of null_create_dev(), and in null_destroy_dev().
> Remove the redundant call.
Looks good to me.
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] drbd: reject data replies with an out-of-range payload size
From: Jens Axboe @ 2026-07-10 15:09 UTC (permalink / raw)
To: Philipp Reisner, Lars Ellenberg, Christoph Boehmwalder,
Michael Bommarito
Cc: drbd-dev, linux-block, linux-kernel
In-Reply-To: <20260710022837.3738461-1-michael.bommarito@gmail.com>
On Thu, 09 Jul 2026 22:28:37 -0400, Michael Bommarito wrote:
> recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an
> outstanding read request. The peer-supplied payload length reaches it as
> the signed int data_size, and two peer-controlled inputs can make it
> negative. With a negotiated data-integrity-alg the digest length is
> subtracted first, so a reply whose payload is smaller than the digest
> underflows data_size. With no integrity algorithm (the default) data_size
> is assigned from the unsigned h95/h100 wire length and drbdd() never
> bounds it for a payload-carrying command, so a length above INT_MAX casts
> it negative; this path needs no non-default feature. The bio receive loop
> then computes expect = min_t(int, data_size, bv_len), which is negative,
> and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX
> into the first mapped page.
>
> [...]
Applied, thanks!
[1/1] drbd: reject data replies with an out-of-range payload size
commit: bd910a7660d280595ef94cb6d193951d855d330f
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] block: remove redundant GD_NEED_PART_SCAN in add_disk_final()
From: Jens Axboe @ 2026-07-10 15:09 UTC (permalink / raw)
To: Connor Williamson
Cc: linux-block, linux-kernel, stable, yukuai3, hch, jack,
nh-open-source
In-Reply-To: <20260615130715.53693-1-connordw@amazon.com>
On Mon, 15 Jun 2026 13:07:15 +0000, Connor Williamson wrote:
> add_disk_final() sets GD_NEED_PART_SCAN before calling bdev_add(),
> then calls disk_scan_partitions() which sets the flag itself. The
> early set is redundant and introduces a race.
>
> Between bdev_add() and disk_scan_partitions(), concurrent openers
> (multipathd, blkid, LVM) see the flag in blkdev_get_whole() and
> trigger bdev_disk_changed(). When disk_scan_partitions() then runs,
> it calls bdev_disk_changed() again, dropping the partitions the
> concurrent opener already created before re-adding them, which can
> result in transient partition disappearances.
>
> [...]
Applied, thanks!
[1/1] block: remove redundant GD_NEED_PART_SCAN in add_disk_final()
commit: 181bb9c9eae4f69fe510a62a42c2932d0314a800
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v15 0/8] blk: honor isolcpus configuration
From: Sebastian Andrzej Siewior @ 2026-07-10 15:14 UTC (permalink / raw)
To: Aaron Tomlin
Cc: axboe, kbusch, hch, sagi, mst, hare, aacraid, James.Bottomley,
martin.petersen, liyihang9, kashyap.desai, sumit.saxena,
shivasharan.srikanteshwara, chandrakanth.patil, sathya.prakash,
sreekanth.reddy, suganath-prabu.subramani, ranjan.kumar,
jinpu.wang, tglx, mingo, peterz, juri.lelli, vincent.guittot,
akpm, maz, ruanjinjie, yphbchou0911, wagi, frederic, longman,
chenridong, kch, ming.lei, tom.leiming, steve, sean, chjohnst,
neelx, mproche, nick.lange, marco.crivellari, rishil1999,
linux-block, linux-kernel
In-Reply-To: <olynqvtm7faqrw3qc2cwvup6vj3rqrr7acbagrgxn5yly7vlpz@yszlwd7afjak>
On 2026-06-17 07:01:24 [-0400], Aaron Tomlin wrote:
> Hi everyone,
Hi,
> I would greatly appreciate it if anyone has the bandwidth to review this
> new approach. Please let me know your thoughts or if there are any further
> refinements needed.
I assume this is the latest. If so I would try to look at this next MON.
> Thank you for your time and guidance.
>
> Kind regards,
Sebastian
^ permalink raw reply
* Re: [PATCH v15 0/8] blk: honor isolcpus configuration
From: Sebastian Andrzej Siewior @ 2026-07-10 15:21 UTC (permalink / raw)
To: Aaron Tomlin
Cc: axboe, kbusch, hch, sagi, mst, aacraid, James.Bottomley,
martin.petersen, liyihang9, kashyap.desai, sumit.saxena,
shivasharan.srikanteshwara, chandrakanth.patil, sathya.prakash,
sreekanth.reddy, suganath-prabu.subramani, ranjan.kumar,
jinpu.wang, tglx, mingo, peterz, juri.lelli, vincent.guittot,
akpm, maz, ruanjinjie, yphbchou0911, wagi, frederic, longman,
chenridong, hare, kch, ming.lei, tom.leiming, steve, sean,
chjohnst, neelx, mproche, nick.lange, marco.crivellari,
rishil1999, linux-block, linux-kernel
In-Reply-To: <20260521232956.553287-1-atomlin@atomlin.com>
On 2026-05-21 19:29:48 [-0400], Aaron Tomlin wrote:
> Hi,
Hi,
> I have decided to drive this series forward on behalf of Daniel Wagner, the
> original author. The series has been rebased on v7.1-rc4-100-g8bc67e4db64a.
>
> This series introduces a new CPU isolation feature, "isolcpus=io_queue",
> designed to protect isolated cores from the disruptive hardware interrupts
> generated by high-performance multi-queue devices.
>
> When enabled, it fundamentally alters how the generic IRQ subsystem and the
> block layer (blk-mq) map hardware queues:
>
> 1. Restricted IRQ Affinity: Managed hardware interrupts are strictly
> confined to online housekeeping CPUs.
>
> 2. Transparent I/O Submission: Applications running on isolated CPUs
> can still seamlessly submit I/O requests; however, the resulting
> hardware completion interrupts are safely routed to a designated
> housekeeping CPU.
>
> 3. Topology-Aware Queue Allocation: The generic CPU-to-hardware-queue
> mapping logic is extended to distribute hardware contexts evenly
> among the available housekeeping CPUs, preventing MSI-X vector
> exhaustion while maintaining optimal cache locality where possible.
>
> To prevent I/O stalls, the block layer is additionally hardened to reject
> hot-plug requests that attempt to offline a housekeeping CPU if it is the
> last remaining CPU actively serving an online isolated core.
>
> The complex "top-down" mask plumbing introduced in v12, which modified
> struct irq_affinity and expanded block layer APIs, has been abandoned. It
> is replaced by a centralised approach: direct isolation querying via
> housekeeping_cpumask(HK_TYPE_IO_QUEUE) within the genirq/affinity
> subsystem. This architectural simplification successfully decouples core
> changes from driver-specific implementations.
>
> Please let me know your thoughts.
I think I asked this or wanted to: Why not mage managed_irqs consider
this? Or is there a case where those two options want a different thing?
With managed_irqs you specify a mask but this is may not be respected if
you have more IRQs than you specify. This means the IRQs will still be
routed to isolated CPUs.
This option is intended to avoid any interrupts on isolated CPUs.
Wouldn't it be possible to allow managed_irqs to restrict a device to
two CPUs only and use two queues only instead of the available 64 or do
I miss something fundamental why those two need to be separate?
Sebastian
^ permalink raw reply
* Re: [PATCH] fs: report direct io constraints through file_getattr
From: Keith Busch @ 2026-07-10 15:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Keith Busch, linux-block, linux-ext4, linux-f2fs-devel,
linux-fsdevel, linux-xfs, axboe, jack, brauner, cem, jaegeuk,
aalbersh, tytso
In-Reply-To: <20260710043519.GA6205@lst.de>
On Fri, Jul 10, 2026 at 06:35:19AM +0200, Christoph Hellwig wrote:
> On Thu, Jul 09, 2026 at 07:46:42AM -0600, Keith Busch wrote:
> > On Thu, Jul 09, 2026 at 09:13:52AM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 07, 2026 at 06:18:43PM -0700, Keith Busch wrote:
> > >
> > > > + fa->fsx_dio_mem_align = bdev_dma_alignment(bdev) + 1;
> > > > + fa->fsx_dio_offset_align = bdev_logical_block_size(bdev);
> > > > + fa->fsx_dio_read_offset_align = bdev_logical_block_size(bdev);
> > > > + fa->fsx_dio_virt_boundary_align = bdev_virt_boundary_alignment(bdev);
> > > > + fa->fsx_max_segments = bdev_max_segments(bdev);
> > >
> > > How is the max_segments value defined in a way that is meaningful to
> > > userspace?
> >
> > It tells you how many sub-sector vectors you can submit in your
> > readv/writev before it needs to add up to a logical block size.
> >
> > Ex: 4k logical block size, 4 byte DMA, 256 max segments. You can define
> > 4-byte iov's in your command, but you'll hit the max segment count
> > before you have a valid IO if they're all that small.
>
> Ah, makes sense. But besides the missing documentation I think
> max_segments is a bit of a misleading name for that.
>
> Something like max_vecs_per_block (although we don't expose blocks
> in the UAPI) or max_vecs_per_granularity (I think grammar wants a word
> with me for that, though...) might be a bit more suitable.
The granularity it has to add up to is defined by the
fsx_dio_offset_align attribute. This is a bit long, but to make that
relationship clear, how about:
fsx_dio_max_vecs_per_offset_align
^ permalink raw reply
page: | 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