* Re: RCU warning off ublk_buf_cleanup() -> mas_for_each()
From: Bernd Schubert @ 2026-04-23 21:51 UTC (permalink / raw)
To: Jens Axboe, Ming Lei
Cc: io-uring, linux-block@vger.kernel.org, Liam R. Howlett
In-Reply-To: <331c739c-d0fd-4c53-bbd5-cbb18f5dfedb@kernel.dk>
On 4/23/26 23:48, Jens Axboe wrote:
> On 4/23/26 3:45 PM, Bernd Schubert wrote:
>>
>>
>> On 4/21/26 19:47, Jens Axboe wrote:
>>> Hi Ming,
>>>
>>> Ran into the below running tests on the current tree:
>>>
>>> =============================
>>> WARNING: suspicious RCU usage
>>> 7.0.0+ #16 Tainted: G N
>>> -----------------------------
>>> lib/maple_tree.c:759 suspicious rcu_dereference_check() usage!
>>>
>>> other info that might help us debug this:
>>>
>>>
>>> rcu_scheduler_active = 2, debug_locks = 1
>>> 1 lock held by iou-wrk-55535/55536:
>>> #0: ffff800085a451a0 (ublk_ctl_mutex){+.+.}-{4:4}, at: ublk_ctrl_del_dev+0xdc/0x2f8
>>>
>>> stack backtrace:
>>> CPU: 4 UID: 0 PID: 55536 Comm: iou-wrk-55535 Tainted: G N 7.0.0+ #16 PREEMPT
>>> Tainted: [N]=TEST
>>> Hardware name: linux,dummy-virt (DT)
>>> Call trace:
>>> show_stack+0x1c/0x30 (C)
>>> dump_stack_lvl+0x68/0x90
>>> dump_stack+0x18/0x20
>>> lockdep_rcu_suspicious+0x170/0x200
>>> mas_walk+0x3f0/0x6a0
>>> mas_find+0x1b4/0x6b0
>>> ublk_buf_cleanup+0xe0/0x240
>>> ublk_cdev_rel+0x34/0x1b0
>>> device_release+0xa4/0x350
>>> kobject_put+0x138/0x250
>>> put_device+0x18/0x30
>>> ublk_put_device+0x18/0x28
>>> ublk_ctrl_del_dev+0x120/0x2f8
>>> ublk_ctrl_uring_cmd+0x598/0x29b8
>>> io_uring_cmd+0x1e0/0x468
>>> __io_issue_sqe+0xa4/0x748
>>> io_issue_sqe+0x80/0xf68
>>> io_wq_submit_work+0x26c/0xdc8
>>> io_worker_handle_work+0x334/0xf20
>>> io_wq_worker+0x278/0x9e8
>>> ret_from_fork+0x10/0x20
>>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>>> ublkb0: unable to read partition table
>>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>>>
>>> and I briefly looked at it, but then just gave up as a) the maple tree
>>> documentation is not that detailed, and b) other in-tree users also just
>>> call mas_for_each() without either a lock held or RCU read side locked.
>>>
>>> Adding Liam for shedding some light on this...
>>>
>>
>> Hmm, that is another one, I run into
>>
>> Date: Thu Apr 16 15:16:04 2026 +0200
>>
>> ublk: Add rcu_read_lock/unlock in ublk_buf_cleanup
>>
>> [ 399.994025] =============================
>> [ 399.994694] WARNING: suspicious RCU usage
>> [ 399.995464] 7.0.0+ #52 Not tainted
>> [ 399.996034] -----------------------------
>> [ 399.996697] lib/maple_tree.c:780 suspicious rcu_dereference_check() usage!
>> [ 399.997748]
>> other info that might help us debug this:
>>
>> [ 399.998961]
>> rcu_scheduler_active = 2, debug_locks = 1
>> [ 399.999957] 1 lock held by iou-wrk-1495/1509:
>> [ 400.000596] #0: ffffffffa05e4590 (ublk_ctl_mutex){+.+.}-{4:4}, at: ublk_ctrl_del_dev+0x3d/0x190 [ublk_drv]
>> [ 400.001796]
>> stack backtrace:
>> [ 400.002492] CPU: 40 UID: 0 PID: 1509 Comm: iou-wrk-1495 Not tainted 7.0.0+ #52 PREEMPT
>> [ 400.002496] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
>> [ 400.002498] Call Trace:
>> [ 400.002500] <TASK>
>> [ 400.002503] dump_stack_lvl+0x54/0x70
>> [ 400.002511] lockdep_rcu_suspicious+0x119/0x160
>> [ 400.002521] mas_start+0xed/0x140
>> [ 400.002531] mas_find+0x1a6/0x270
>> [ 400.002538] ublk_cdev_rel+0xb8/0x320 [ublk_drv]
>>
>>
>> And have in my pbuf branch
>>
>> index eb9b5dd8122c..208f6b5ad892 100644
>> --- a/drivers/block/ublk_drv.c
>> +++ b/drivers/block/ublk_drv.c
>> @@ -5478,6 +5478,7 @@ static void ublk_buf_cleanup(struct ublk_device *ub)
>> struct ublk_buf_range *range;
>> struct page *pages[32];
>>
>> + rcu_read_lock();
>> mas_for_each(&mas, range, ULONG_MAX) {
>> unsigned long base = mas.index;
>> unsigned long nr = mas.last - base + 1;
>> @@ -5495,6 +5496,7 @@ static void ublk_buf_cleanup(struct ublk_device *ub)
>> }
>> kfree(range);
>> }
>> + rcu_read_unlock();
>> mtree_destroy(&ub->buf_tree);
>> ida_destroy(&ub->buf_ida);
>> }
>
> Fixed in patches going to Linus tomorrow, see HEAD~3..HEAD~1 in this
> branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=block-7.1
>
Thank you, will check after getting some sleep.
^ permalink raw reply
* Re: RCU warning off ublk_buf_cleanup() -> mas_for_each()
From: Jens Axboe @ 2026-04-23 21:48 UTC (permalink / raw)
To: Bernd Schubert, Ming Lei
Cc: io-uring, linux-block@vger.kernel.org, Liam R. Howlett
In-Reply-To: <053fa6e7-43f7-4c80-9996-7fe6d8c28e45@bsbernd.com>
On 4/23/26 3:45 PM, Bernd Schubert wrote:
>
>
> On 4/21/26 19:47, Jens Axboe wrote:
>> Hi Ming,
>>
>> Ran into the below running tests on the current tree:
>>
>> =============================
>> WARNING: suspicious RCU usage
>> 7.0.0+ #16 Tainted: G N
>> -----------------------------
>> lib/maple_tree.c:759 suspicious rcu_dereference_check() usage!
>>
>> other info that might help us debug this:
>>
>>
>> rcu_scheduler_active = 2, debug_locks = 1
>> 1 lock held by iou-wrk-55535/55536:
>> #0: ffff800085a451a0 (ublk_ctl_mutex){+.+.}-{4:4}, at: ublk_ctrl_del_dev+0xdc/0x2f8
>>
>> stack backtrace:
>> CPU: 4 UID: 0 PID: 55536 Comm: iou-wrk-55535 Tainted: G N 7.0.0+ #16 PREEMPT
>> Tainted: [N]=TEST
>> Hardware name: linux,dummy-virt (DT)
>> Call trace:
>> show_stack+0x1c/0x30 (C)
>> dump_stack_lvl+0x68/0x90
>> dump_stack+0x18/0x20
>> lockdep_rcu_suspicious+0x170/0x200
>> mas_walk+0x3f0/0x6a0
>> mas_find+0x1b4/0x6b0
>> ublk_buf_cleanup+0xe0/0x240
>> ublk_cdev_rel+0x34/0x1b0
>> device_release+0xa4/0x350
>> kobject_put+0x138/0x250
>> put_device+0x18/0x30
>> ublk_put_device+0x18/0x28
>> ublk_ctrl_del_dev+0x120/0x2f8
>> ublk_ctrl_uring_cmd+0x598/0x29b8
>> io_uring_cmd+0x1e0/0x468
>> __io_issue_sqe+0xa4/0x748
>> io_issue_sqe+0x80/0xf68
>> io_wq_submit_work+0x26c/0xdc8
>> io_worker_handle_work+0x334/0xf20
>> io_wq_worker+0x278/0x9e8
>> ret_from_fork+0x10/0x20
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> ublkb0: unable to read partition table
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>>
>> and I briefly looked at it, but then just gave up as a) the maple tree
>> documentation is not that detailed, and b) other in-tree users also just
>> call mas_for_each() without either a lock held or RCU read side locked.
>>
>> Adding Liam for shedding some light on this...
>>
>
> Hmm, that is another one, I run into
>
> Date: Thu Apr 16 15:16:04 2026 +0200
>
> ublk: Add rcu_read_lock/unlock in ublk_buf_cleanup
>
> [ 399.994025] =============================
> [ 399.994694] WARNING: suspicious RCU usage
> [ 399.995464] 7.0.0+ #52 Not tainted
> [ 399.996034] -----------------------------
> [ 399.996697] lib/maple_tree.c:780 suspicious rcu_dereference_check() usage!
> [ 399.997748]
> other info that might help us debug this:
>
> [ 399.998961]
> rcu_scheduler_active = 2, debug_locks = 1
> [ 399.999957] 1 lock held by iou-wrk-1495/1509:
> [ 400.000596] #0: ffffffffa05e4590 (ublk_ctl_mutex){+.+.}-{4:4}, at: ublk_ctrl_del_dev+0x3d/0x190 [ublk_drv]
> [ 400.001796]
> stack backtrace:
> [ 400.002492] CPU: 40 UID: 0 PID: 1509 Comm: iou-wrk-1495 Not tainted 7.0.0+ #52 PREEMPT
> [ 400.002496] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
> [ 400.002498] Call Trace:
> [ 400.002500] <TASK>
> [ 400.002503] dump_stack_lvl+0x54/0x70
> [ 400.002511] lockdep_rcu_suspicious+0x119/0x160
> [ 400.002521] mas_start+0xed/0x140
> [ 400.002531] mas_find+0x1a6/0x270
> [ 400.002538] ublk_cdev_rel+0xb8/0x320 [ublk_drv]
>
>
> And have in my pbuf branch
>
> index eb9b5dd8122c..208f6b5ad892 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -5478,6 +5478,7 @@ static void ublk_buf_cleanup(struct ublk_device *ub)
> struct ublk_buf_range *range;
> struct page *pages[32];
>
> + rcu_read_lock();
> mas_for_each(&mas, range, ULONG_MAX) {
> unsigned long base = mas.index;
> unsigned long nr = mas.last - base + 1;
> @@ -5495,6 +5496,7 @@ static void ublk_buf_cleanup(struct ublk_device *ub)
> }
> kfree(range);
> }
> + rcu_read_unlock();
> mtree_destroy(&ub->buf_tree);
> ida_destroy(&ub->buf_ida);
> }
Fixed in patches going to Linus tomorrow, see HEAD~3..HEAD~1 in this
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=block-7.1
--
Jens Axboe
^ permalink raw reply
* Re: RCU warning off ublk_buf_cleanup() -> mas_for_each()
From: Bernd Schubert @ 2026-04-23 21:45 UTC (permalink / raw)
To: Jens Axboe, Ming Lei
Cc: io-uring, linux-block@vger.kernel.org, Liam R. Howlett
In-Reply-To: <0349d72d-dff8-4f9f-b448-919fa5ae96da@kernel.dk>
On 4/21/26 19:47, Jens Axboe wrote:
> Hi Ming,
>
> Ran into the below running tests on the current tree:
>
> =============================
> WARNING: suspicious RCU usage
> 7.0.0+ #16 Tainted: G N
> -----------------------------
> lib/maple_tree.c:759 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by iou-wrk-55535/55536:
> #0: ffff800085a451a0 (ublk_ctl_mutex){+.+.}-{4:4}, at: ublk_ctrl_del_dev+0xdc/0x2f8
>
> stack backtrace:
> CPU: 4 UID: 0 PID: 55536 Comm: iou-wrk-55535 Tainted: G N 7.0.0+ #16 PREEMPT
> Tainted: [N]=TEST
> Hardware name: linux,dummy-virt (DT)
> Call trace:
> show_stack+0x1c/0x30 (C)
> dump_stack_lvl+0x68/0x90
> dump_stack+0x18/0x20
> lockdep_rcu_suspicious+0x170/0x200
> mas_walk+0x3f0/0x6a0
> mas_find+0x1b4/0x6b0
> ublk_buf_cleanup+0xe0/0x240
> ublk_cdev_rel+0x34/0x1b0
> device_release+0xa4/0x350
> kobject_put+0x138/0x250
> put_device+0x18/0x30
> ublk_put_device+0x18/0x28
> ublk_ctrl_del_dev+0x120/0x2f8
> ublk_ctrl_uring_cmd+0x598/0x29b8
> io_uring_cmd+0x1e0/0x468
> __io_issue_sqe+0xa4/0x748
> io_issue_sqe+0x80/0xf68
> io_wq_submit_work+0x26c/0xdc8
> io_worker_handle_work+0x334/0xf20
> io_wq_worker+0x278/0x9e8
> ret_from_fork+0x10/0x20
> Buffer I/O error on dev ublkb0, logical block 0, async page read
> Buffer I/O error on dev ublkb0, logical block 0, async page read
> ublkb0: unable to read partition table
> Buffer I/O error on dev ublkb0, logical block 0, async page read
> Buffer I/O error on dev ublkb0, logical block 0, async page read
> Buffer I/O error on dev ublkb0, logical block 512, async page read
> Buffer I/O error on dev ublkb0, logical block 512, async page read
> Buffer I/O error on dev ublkb0, logical block 0, async page read
> Buffer I/O error on dev ublkb0, logical block 512, async page read
>
> and I briefly looked at it, but then just gave up as a) the maple tree
> documentation is not that detailed, and b) other in-tree users also just
> call mas_for_each() without either a lock held or RCU read side locked.
>
> Adding Liam for shedding some light on this...
>
Hmm, that is another one, I run into
Date: Thu Apr 16 15:16:04 2026 +0200
ublk: Add rcu_read_lock/unlock in ublk_buf_cleanup
[ 399.994025] =============================
[ 399.994694] WARNING: suspicious RCU usage
[ 399.995464] 7.0.0+ #52 Not tainted
[ 399.996034] -----------------------------
[ 399.996697] lib/maple_tree.c:780 suspicious rcu_dereference_check() usage!
[ 399.997748]
other info that might help us debug this:
[ 399.998961]
rcu_scheduler_active = 2, debug_locks = 1
[ 399.999957] 1 lock held by iou-wrk-1495/1509:
[ 400.000596] #0: ffffffffa05e4590 (ublk_ctl_mutex){+.+.}-{4:4}, at: ublk_ctrl_del_dev+0x3d/0x190 [ublk_drv]
[ 400.001796]
stack backtrace:
[ 400.002492] CPU: 40 UID: 0 PID: 1509 Comm: iou-wrk-1495 Not tainted 7.0.0+ #52 PREEMPT
[ 400.002496] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
[ 400.002498] Call Trace:
[ 400.002500] <TASK>
[ 400.002503] dump_stack_lvl+0x54/0x70
[ 400.002511] lockdep_rcu_suspicious+0x119/0x160
[ 400.002521] mas_start+0xed/0x140
[ 400.002531] mas_find+0x1a6/0x270
[ 400.002538] ublk_cdev_rel+0xb8/0x320 [ublk_drv]
And have in my pbuf branch
index eb9b5dd8122c..208f6b5ad892 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -5478,6 +5478,7 @@ static void ublk_buf_cleanup(struct ublk_device *ub)
struct ublk_buf_range *range;
struct page *pages[32];
+ rcu_read_lock();
mas_for_each(&mas, range, ULONG_MAX) {
unsigned long base = mas.index;
unsigned long nr = mas.last - base + 1;
@@ -5495,6 +5496,7 @@ static void ublk_buf_cleanup(struct ublk_device *ub)
}
kfree(range);
}
+ rcu_read_unlock();
mtree_destroy(&ub->buf_tree);
ida_destroy(&ub->buf_ida);
}
Thanks,
Bernd
^ permalink raw reply related
* Re: [PATCH v2] cdrom, scsi: sr: propagate read-only status to block layer via set_disk_ro()
From: Phillip Potter @ 2026-04-23 21:06 UTC (permalink / raw)
To: Daan De Meyer
Cc: martin.petersen, James.Bottomley, axboe, linux-scsi, linux-block,
linux-kernel, Daan De Meyer
In-Reply-To: <20260422113206.246267-1-daan@amutable.com>
On Wed, Apr 22, 2026 at 11:32:06AM +0000, Daan De Meyer wrote:
> The cdrom core never calls set_disk_ro() for a registered device, so
> BLKROGET on a CD-ROM device always returns 0 (writable), even when the
> drive has no write capabilities and writes will inevitably fail. This
> causes problems for userspace that relies on BLKROGET to determine
> whether a block device is read-only. For example, systemd's loop device
> setup uses BLKROGET to decide whether to create a loop device with
> LO_FLAGS_READ_ONLY. Without the read-only flag, writes pass through the
> loop device to the CD-ROM and fail with I/O errors. systemd-fsck
> similarly checks BLKROGET to decide whether to run fsck in no-repair
> mode (-n).
>
> The write-capability bits in cdi->mask come from two different sources:
> CDC_DVD_RAM and CDC_CD_RW are populated by the driver from the MODE
> SENSE capabilities page (page 0x2A) before register_cdrom() is called,
> while CDC_MRW_W and CDC_RAM require the MMC GET CONFIGURATION command
> and were only probed by cdrom_open_write() at device open time. This
> meant that any attempt to compute the writable state from the full
> mask at probe time was incorrect, because the GET CONFIGURATION bits
> were still unset (and cdi->mask is initialized such that capabilities
> are assumed present).
>
> Fix this by factoring the GET CONFIGURATION probing out of
> cdrom_open_write() into a new exported helper,
> cdrom_probe_write_features(), and having sr call it from sr_probe()
> right after get_capabilities() has populated the MODE SENSE bits.
> register_cdrom() then calls set_disk_ro() based on the full
> write-capability mask (CDC_DVD_RAM | CDC_MRW_W | CDC_RAM | CDC_CD_RW)
> so the block layer reflects the drive's actual write support. The
> feature queries used (CDF_MRW and CDF_RWRT via GET CONFIGURATION with
> RT=00) report drive-level capabilities that are persistent across
> media, so a single probe before register_cdrom() is sufficient and the
> redundant probe at open time is dropped.
>
> With set_disk_ro() now accurate, the long-vestigial cd->writeable flag
> in sr can go: get_capabilities() used to set cd->writeable based on
> the same four mask bits, but because CDC_MRW_W and CDC_RAM default to
> "capability present" in cdi->mask and aren't touched by MODE SENSE,
> the condition that gated cd->writeable was always true, making it
> unconditionally 1. Replace the corresponding gate in sr_init_command()
> with get_disk_ro(cd->disk), which turns a previously no-op check into
> a real one and also catches kernel-internal bio writers that bypass
> blkdev_write_iter()'s bdev_read_only() check.
>
> The sd driver (SCSI disks) does not have this problem because it
> checks the MODE SENSE Write Protect bit and calls set_disk_ro()
> accordingly. The sr driver cannot use the same approach because the
> MMC specification does not define the WP bit in the MODE SENSE
> device-specific parameter byte for CD-ROM devices.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Daan De Meyer <daan@amutable.com>
Hi Daan,
Thank you for the patch. I will properly review it and build test etc.
this weekend and come back to you, hope that's ok.
Regards,
Phil
^ permalink raw reply
* Re: 10x I/O await times in 6.12
From: Matt Fleming @ 2026-04-23 18:18 UTC (permalink / raw)
To: Yu Kuai, Jens Axboe
Cc: Matt Fleming, linux-block, linux-kernel, kernel-team, yukuai (C)
In-Reply-To: <dd2db843-843f-db15-c54f-f2c44548dee3@huaweicloud.com>
Hi Yu and Jens,
On Mon, Apr 21, 2025 at 08:21:13PM +0800, Yu Kuai wrote:
> If nsecs - plug->cur_ktime is still milliseconds, can you check if
> the following patch can fix your problem?
>
> Thanks,
> Kuai
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index ae8494d88897..37197502147e 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1095,7 +1095,9 @@ static inline void blk_account_io_start(struct request
> *req)
> return;
>
> req->rq_flags |= RQF_IO_STAT;
> - req->start_time_ns = blk_time_get_ns();
> +
> + if (!current->plug)
> + req->start_time_ns = blk_time_get_ns();
>
> /*
> * All non-passthrough requests are created from a bio with one
> @@ -2874,6 +2876,7 @@ void blk_mq_flush_plug_list(struct blk_plug *plug,
> bool from_schedule)
> {
> struct request *rq;
> unsigned int depth;
> + u64 now;
>
> /*
> * We may have been called recursively midway through handling
> @@ -2887,6 +2890,10 @@ void blk_mq_flush_plug_list(struct blk_plug *plug,
> bool from_schedule)
> depth = plug->rq_count;
> plug->rq_count = 0;
>
> + now = ktime_get_ns();
> + rq_list_for_each(&plug->mq_list, rq)
> + rq->start_time_ns = now;
> +
> if (!plug->multiple_queues && !plug->has_elevator && !from_schedule)
> {
> struct request_queue *q;
>
It's April again, and this time we're moving to 6.18.
The I/O accounting bug reported at the start of this thread is still an
issue for us, and we've been carrying the above patch for 12 months.
Digging into this a bit more, the issue appears to be big writeback
(e.g. xfsaild invoking xfs_buf_delwri_submit_nowait()), where one plug
covers hundreds of writes for around 10ms on average.
xfsaild can stay on-CPU for long stretches which leads to inflated I/O
times in /proc/diskstats. Tracing the requests shows that they're not
actually any slower than previous kernel versions -- it's purely an
accounting bug.
Of course it doesn't look to be an XFS thing. It's just tasks doing
massive writes without getting preempted/interrupted.
Any interest in merging the above patch?
Thanks,
Matt
^ permalink raw reply
* Re: [PATCH v3 0/6] block: fix integrity offset/length conversions
From: Caleb Sander Mateos @ 2026-04-23 18:02 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Jens Axboe, Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Anuj Gupta, linux-block, linux-nvme, linux-scsi, target-devel,
linux-kernel
In-Reply-To: <yq15x5lqfdx.fsf@ca-mkp.ca.oracle.com>
On Mon, Apr 20, 2026 at 7:09 PM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
>
> Hi Caleb!
>
> > NVM Command Set specification 1.1 section 5.3.3 requires the reference
> > tag to increment by 1 per logical block, so that seems to determine
> > the increment unit:
>
> SCSI allows PI to be interleaved at intervals smaller than the logical
> block size. This was done for PI compatibility in mixed environments
> with both 512[en] and 4Kn disks. Interleaving allows 8 bytes of PI per
> 512 bytes of data on devices using 4 KB logical blocks. That is the
> reason why we use the term "integrity interval" instead of assuming
> logical block size.
Thanks for the explanation, I'm not too familiar with SCSI. I meant to
refer to integrity intervals in my explanation if they differ from the
logical block size.
>
> > The ref tag used for a particular block needs to be consistent. And
> > since reftag(block N) can be computed as the reftag(M) + N - M if
> > block N is accessed as part of an I/O that begins at block M, the
> > function must be of the form reftag(block N) = N + c for some constant
> > c. Thus, the ref tag seed needs to be computed in units of logical
> > blocks (integrity intervals); no other unit (e.g. 512-byte sectors)
> > works.
>
> Whoever attaches the PI decides on the seed value. In the case of the
> block layer it made sense to use block layer sector number since that
> value is inevitably going to be the same for a future read.
I'm not following "going to be the same for a future read". The block
can be read back by an I/O with a different starting
offset/sector/seed, as my example illustrates. When the integrity
interval size differs from the sector size (512 bytes), mixing the two
units results in a different ref tag seed for the block depending on
the starting offset of the I/O.
>
> Note that with MD, DM, and partitioning in the mix, the sector number
> seen by whoever submits the I/O is going to be different from the LBAs
> on the target devices which eventually receive the I/O. Nobody says
> there is a computable constant offset. Think scattered LVM extent
> allocations. Or RAID stripes placed at mismatched LBA offsets.
The constant offset relationship still needs to hold over any
contiguous range of a backing block device that can be accessed by a
single I/O. For example, with partitions, it's not possible for a
single I/O to cross a partition boundary, so each partition can have a
different constant offset between the ref tags and absolute integrity
interval numbers. With RAID, each shard can have a different constant
offset. etc.
>
> > To see the issue with the current approach, consider an example
> > accessing LBA 1 on a device with a 4 KB block size. If the block is
> > written as part of a write that begins at LBA 0, its ref tag in the
> > generated PI will be 1 (sector 0 + 1 integrity interval). If it's
> > later read by a read starting at LBA 1, its expected ref tag will be 8
> > (sector 8 + 0 integrity intervals), and the auto-integrity code will
> > fail the read due to a reftag mismatch.
>
> Something is broken, then. Because the ref tag in the received PI should
> have been remapped to start at 8 in that case.
Ah, I missed the remapping piece. Thanks for pointing that out. I
guess I was testing with a ublk device that doesn't advertise
BLK_INTEGRITY_REF_TAG. Since commit 203247c5cb97 ("blk-integrity:
support arbitrary buffer alignment"), the ref tag is unconditionally
set in the PI from the (sector) seed, but the remapping is conditional
on BLK_INTEGRITY_REF_TAG. That explains why I was seeing ref tags in
the PI that didn't match the integrity interval numbers.
So seems like patch 1 ("block: use integrity interval instead of
sector as seed") doesn't need a Fixes tag. Still, I'm confused why the
auto-integrity code bothers setting the seed to the sector number in
the first place if it's going to be remapped later. Why not just leave
the seed zeroed?
Best,
Caleb
>
> > I agree, the seed doesn't need to match the final LBA, but it does
> > need to be in *units* of logical blocks, plus some constant offset.
>
> Your concept of "unit" still sends the wrong message. The seed is an
> integer value used to initialize a counter or hardware register. The
> seed only has meaning to whichever entity submits the I/O. To everything
> else it is a value used for remapping ref tags from the I/O submitter's
> point of view to whichever interpretation is mandated by the storage
> hardware's PI format.
>
> > With a ublk device. It should affect any block device that supports
> > integrity and has a logical block size > 512.
>
> It sounds like the seed value is set incorrectly for reads in your
> configuration.
>
> --
> Martin K. Petersen
^ permalink raw reply
* [syzbot] [block?] KASAN: slab-out-of-bounds Read in blk_mq_free_rqs
From: syzbot @ 2026-04-23 17:45 UTC (permalink / raw)
To: axboe, linux-block, linux-kernel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 8a30aeb0d1b4 Merge tag 'nfsd-7.0-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=163e72da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=555131780f7c7272
dashboard link: https://syzkaller.appspot.com/bug?extid=e90526cab23b9efcd03c
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/2dc05dfe27bf/disk-8a30aeb0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ec5900e43ce7/vmlinux-8a30aeb0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/66501ac91f88/bzImage-8a30aeb0.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e90526cab23b9efcd03c@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in blk_mq_free_rqs+0x6e2/0x760 block/blk-mq.c:3486
Read of size 8 at addr ffff888027b4f7e8 by task syz.3.686/9329
CPU: 0 UID: 0 PID: 9329 Comm: syz.3.686 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x156/0x4c9 mm/kasan/report.c:482
kasan_report+0xdf/0x1e0 mm/kasan/report.c:595
blk_mq_free_rqs+0x6e2/0x760 block/blk-mq.c:3486
blk_mq_free_map_and_rqs block/blk-mq.c:4157 [inline]
blk_mq_free_map_and_rqs+0x30/0x120 block/blk-mq.c:4152
blk_mq_free_sched_tags+0xeb/0x1b0 block/blk-mq-sched.c:425
blk_mq_free_sched_res+0x52/0x150 block/blk-mq-sched.c:436
elevator_change_done+0x187/0x650 block/elevator.c:639
elevator_change+0x2d7/0x530 block/elevator.c:685
elevator_set_none+0x92/0xf0 block/elevator.c:769
blk_mq_elv_switch_none block/blk-mq.c:5110 [inline]
__blk_mq_update_nr_hw_queues block/blk-mq.c:5155 [inline]
blk_mq_update_nr_hw_queues+0x4c1/0x15f0 block/blk-mq.c:5220
nbd_start_device+0x1a6/0xbd0 drivers/block/nbd.c:1489
nbd_start_device_ioctl drivers/block/nbd.c:1548 [inline]
__nbd_ioctl drivers/block/nbd.c:1623 [inline]
nbd_ioctl+0x4a6/0xd30 drivers/block/nbd.c:1663
blkdev_ioctl+0x5ad/0x6f0 block/ioctl.c:804
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f854359c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f854451d028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f8543815fa0 RCX: 00007f854359c799
RDX: 0000000000000000 RSI: 000000000000ab03 RDI: 0000000000000003
RBP: 00007f8543632c99 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f8543816038 R14: 00007f8543815fa0 R15: 00007ffc336cfa78
</TASK>
Allocated by task 1:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__do_kmalloc_node mm/slub.c:5260 [inline]
__kmalloc_node_noprof+0x307/0x850 mm/slub.c:5266
kmalloc_array_node_noprof include/linux/slab.h:1169 [inline]
blk_mq_alloc_tag_set+0x477/0x1330 block/blk-mq.c:4903
nbd_dev_add+0x342/0xb10 drivers/block/nbd.c:1933
nbd_init+0x291/0x2b0 drivers/block/nbd.c:2692
do_one_initcall+0x11d/0x760 init/main.c:1382
do_initcall_level init/main.c:1444 [inline]
do_initcalls init/main.c:1460 [inline]
do_basic_setup init/main.c:1479 [inline]
kernel_init_freeable+0x6e5/0x7a0 init/main.c:1692
kernel_init+0x1f/0x1e0 init/main.c:1582
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff888027b4f7e0
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes to the right of
allocated 8-byte region [ffff888027b4f7e0, ffff888027b4f7e8)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888027b4f680 pfn:0x27b4f
flags: 0xfff00000000200(workingset|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000200 ffff88813fe39500 ffffea0000abdd90 ffffea0000d70550
raw: ffff888027b4f680 000000080080007b 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2c00(GFP_NOIO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 5607902614, free_ts 5601697774
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x111d/0x3140 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x27c/0x2ba0 mm/page_alloc.c:5250
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+0x26b/0x400 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x1ab/0x660 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_node_track_caller_noprof+0x694/0x850 mm/slub.c:5368
__kmemdup_nul mm/util.c:64 [inline]
kstrdup+0x51/0xe0 mm/util.c:84
kstrdup_const+0x63/0x80 mm/util.c:104
__kernfs_new_node+0x9b/0x960 fs/kernfs/dir.c:633
kernfs_new_node+0x11b/0x1a0 fs/kernfs/dir.c:718
kernfs_create_link+0xcc/0x240 fs/kernfs/symlink.c:39
sysfs_do_create_link_sd+0x90/0x140 fs/sysfs/symlink.c:44
sysfs_do_create_link fs/sysfs/symlink.c:80 [inline]
sysfs_create_link+0x61/0xc0 fs/sysfs/symlink.c:92
device_add_class_symlinks drivers/base/core.c:3448 [inline]
device_add+0x675/0x1950 drivers/base/core.c:3640
__add_disk+0x518/0xe40 block/genhd.c:496
page last free pid 10 tgid 10 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0x7e1/0x10d0 mm/page_alloc.c:2978
vfree.part.0+0x12b/0x9d0 mm/vmalloc.c:3479
vfree mm/vmalloc.c:3456 [inline]
delayed_vfree_work+0x8e/0xd0 mm/vmalloc.c:3398
process_one_work+0xa23/0x19a0 kernel/workqueue.c:3276
process_scheduled_works kernel/workqueue.c:3359 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3440
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff888027b4f680: fa fc fc fc fa fc fc fc fa fc fc fc 05 fc fc fc
ffff888027b4f700: 06 fc fc fc 05 fc fc fc 05 fc fc fc 05 fc fc fc
>ffff888027b4f780: 00 fc fc fc 05 fc fc fc 00 fc fc fc 00 fc fc fc
^
ffff888027b4f800: 06 fc fc fc 06 fc fc fc 06 fc fc fc 05 fc fc fc
ffff888027b4f880: 05 fc fc fc 05 fc fc fc 05 fc fc fc 02 fc fc fc
==================================================================
block nbd3: shutting down sockets
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [RFC PATCH v2 2/4] mm/zsmalloc: introduce zs_free_deferred() for async handle freeing
From: Nhat Pham @ 2026-04-23 16:40 UTC (permalink / raw)
To: Barry Song
Cc: Wenchao Hao, Andrew Morton, Chengming Zhou, Jens Axboe,
Johannes Weiner, Minchan Kim, Sergey Senozhatsky, Yosry Ahmed,
linux-block, linux-kernel, linux-mm, Xueyuan Chen, Wenchao Hao
In-Reply-To: <CAGsJ_4xosgszLBGXdXGchgYW6ks_XB1vO35scrO0UUiQ1ZvVvQ@mail.gmail.com>
On Tue, Apr 21, 2026 at 2:42 PM Barry Song <baohua@kernel.org> wrote:
> On Wed, Apr 22, 2026 at 3:47 AM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Tue, Apr 21, 2026 at 5:16 AM Wenchao Hao <haowenchao22@gmail.com> wrote:
> > >
> > > zs_free() is expensive due to internal locking (pool->lock, class->lock)
> > > and potential zspage freeing. On the process exit path, the slow
> > > zs_free() blocks memory reclamation, delaying overall memory release.
> > > This has been reported to significantly impact Android low-memory
> > > killing where slot_free() accounts for over 80% of the total swap
> > > entry freeing cost.
> > >
> > > Introduce zs_free_deferred() which queues handles into a fixed-size
> > > per-pool array for later processing by a workqueue. This allows callers
> > > to defer the expensive zs_free() and return quickly, so the process
> > > exit path can release memory faster. The array capacity is derived from
> > > a 128MB uncompressed data budget (128MB >> PAGE_SHIFT entries), which
> > > scales naturally with PAGE_SIZE. When the array reaches half capacity,
> > > the workqueue is scheduled to drain pending handles.
> > >
> > > zs_free_deferred() uses spin_trylock() to access the deferred queue.
> > > If the lock is contended (e.g. drain in progress) or the queue is full,
> > > it falls back to synchronous zs_free() to guarantee correctness.
> > >
> > > Also introduce zs_free_deferred_flush() for use during pool teardown to
> > > ensure all pending handles are freed.
> >
> > Hmmm per-pool workqueue.
> >
> > Does that mean that if you only have one zs pool (in the case of
> > zswap, or if you only have one zram device), you'll have less
> > concurrency in freeing up zsmalloc memory for process teardown? Would
> > this be problematic?
>
> I believe so, as reported in the original email from Lei and Zhiguo,
> which proposed introducing a swap entries list for async free.
>
> >
> > I think Kairui was also suggesting per-cpu-fying these batches/queues.
>
> I guess a per–size-class workqueue might strike a balance
> between scalability and reducing lock contention across
> multiple classes, where the locks actually reside.
Sounds good! Let the numbers decide :)
>
> Thanks
> Barry
^ permalink raw reply
* [PATCH] sched: disable preemption around blk_flush_plug in sched_submit_work
From: Ming Lei @ 2026-04-23 12:55 UTC (permalink / raw)
To: Jens Axboe, linux-block; +Cc: linux-kernel, Ming Lei, Michael Wu
On preemptible kernels, a three-way deadlock can occur involving
blk_mq_freeze_queue and blk_mq_dispatch_list:
- Task A holds a filesystem lock (e.g., f2fs io_rwsem) and enters
__bio_queue_enter(), waiting for mq_freeze_depth == 0
- Task B holds mq_freeze_depth=1 (elevator_change) and waits for
q_usage_counter to reach zero in blk_mq_freeze_queue_wait()
- Task C is going to sleep waiting for the filesystem lock. Before
sleeping, schedule() calls sched_submit_work() -> blk_flush_plug()
-> blk_mq_dispatch_list(), which acquires q_usage_counter via
percpu_ref_get(). If Task C gets preempted before percpu_ref_put(),
it will not be scheduled back because the task is already in
uninterruptible sleep state (TASK_UNINTERRUPTIBLE). This means it
holds the percpu_ref indefinitely, preventing freeze from completing.
This is fundamentally an ABBA deadlock between queue freeze and the
filesystem lock, exposed by preemption creating an artificial hold
on q_usage_counter during the plug flush.
Fix by disabling preemption around blk_flush_plug() in
sched_submit_work(). The _notrace variants are used since this runs
in scheduler context. preempt_enable_no_resched_notrace() is correct
because we are already inside __schedule() and about to pick the next
task.
Fixes: 73c101011926 ("block: initial patch for on-stack per-task plugging")
Reported-by: Michael Wu <michael@allwinnertech.com>
Tested-by: Michael Wu <michael@allwinnertech.com>
Link: https://lore.kernel.org/linux-block/20260417082744.30124-1-michael@allwinnertech.com/
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
kernel/sched/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b7f77c165a6e..4217aaaa8e47 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6966,7 +6966,9 @@ static inline void sched_submit_work(struct task_struct *tsk)
* If we are going to sleep and we have plugged IO queued,
* make sure to submit it to avoid deadlocks.
*/
+ preempt_disable_notrace();
blk_flush_plug(tsk->plug, true);
+ preempt_enable_no_resched_notrace();
lock_map_release(&sched_map);
}
--
2.53.0
^ permalink raw reply related
* [PATCHv3] ublk: persistent device links
From: Hannes Reinecke @ 2026-04-23 12:17 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, Ming Lei, Hannes Reinecke
Implement a 'uuid' parameter to export a device UUID in a sysfs
attribute 'uuid'. The ublk server is required to set the uuid
parameter when creating the device.
This allows udev to create persistent device links for ublk devices
eg with this rule:
KERNEL=="ublk*", ATTRS{uuid}=="?*", SYMLINK+="disk/by-id/ublk-$attr{uuid}"
Signed-off-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
---
drivers/block/ublk_drv.c | 55 +++++++++++++++++++++++++++++++++--
include/uapi/linux/ublk_cmd.h | 6 ++++
2 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index eb96010625e5..2c7bbea27cbe 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -92,7 +92,7 @@
(UBLK_PARAM_TYPE_BASIC | UBLK_PARAM_TYPE_DISCARD | \
UBLK_PARAM_TYPE_DEVT | UBLK_PARAM_TYPE_ZONED | \
UBLK_PARAM_TYPE_DMA_ALIGN | UBLK_PARAM_TYPE_SEGMENT | \
- UBLK_PARAM_TYPE_INTEGRITY)
+ UBLK_PARAM_TYPE_INTEGRITY | UBLK_PARAM_TYPE_UUID)
#define UBLK_BATCH_F_ALL \
(UBLK_BATCH_F_HAS_ZONE_LBA | \
@@ -938,6 +938,14 @@ static int ublk_validate_params(const struct ublk_device *ub)
return -EINVAL;
}
+ if (ub->params.types & UBLK_PARAM_TYPE_UUID) {
+ const struct ublk_param_uuid *p = &ub->params.uuid;
+ uuid_t uuid;
+
+ import_uuid(&uuid, p->uuid);
+ if (uuid_is_null(&uuid))
+ return -EINVAL;
+ }
return 0;
}
@@ -4251,6 +4259,49 @@ static int ublk_add_chdev(struct ublk_device *ub)
return ret;
}
+static ssize_t uuid_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct gendisk *disk = dev_to_disk(dev);
+ struct ublk_device *ub = disk->private_data;
+ const struct ublk_param_uuid *p = &ub->params.uuid;
+ uuid_t uuid;
+
+ import_uuid(&uuid, p->uuid);
+ return sprintf(buf, "%pU\n", &uuid);
+}
+
+static DEVICE_ATTR_RO(uuid);
+
+static struct attribute *ublk_attrs[] = {
+ &dev_attr_uuid.attr,
+ NULL,
+};
+
+static umode_t ublk_attrs_are_visible(struct kobject *kobj,
+ struct attribute *a, int n)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct gendisk *disk = dev_to_disk(dev);
+ struct ublk_device *ub = disk->private_data;
+
+ if (a == &dev_attr_uuid.attr &&
+ (ub->params.types & UBLK_PARAM_TYPE_UUID))
+ return S_IRUGO;
+
+ return a->mode;
+}
+
+static const struct attribute_group ublk_attr_group = {
+ .attrs = ublk_attrs,
+ .is_visible = ublk_attrs_are_visible,
+};
+
+static const struct attribute_group *ublk_attr_groups[] = {
+ &ublk_attr_group,
+ NULL,
+};
+
/* align max io buffer size with PAGE_SIZE */
static void ublk_align_max_io_size(struct ublk_device *ub)
{
@@ -4446,7 +4497,7 @@ static int ublk_ctrl_start_dev(struct ublk_device *ub,
goto out_put_cdev;
}
- ret = add_disk(disk);
+ ret = device_add_disk(NULL, disk, ublk_attr_groups);
if (ret)
goto out_put_cdev;
diff --git a/include/uapi/linux/ublk_cmd.h b/include/uapi/linux/ublk_cmd.h
index a88876756805..897848b869df 100644
--- a/include/uapi/linux/ublk_cmd.h
+++ b/include/uapi/linux/ublk_cmd.h
@@ -717,6 +717,10 @@ struct ublk_param_integrity {
__u8 pad[5];
};
+struct ublk_param_uuid {
+ __u8 uuid[16];
+};
+
struct ublk_params {
/*
* Total length of parameters, userspace has to set 'len' for both
@@ -732,6 +736,7 @@ struct ublk_params {
#define UBLK_PARAM_TYPE_DMA_ALIGN (1 << 4)
#define UBLK_PARAM_TYPE_SEGMENT (1 << 5)
#define UBLK_PARAM_TYPE_INTEGRITY (1 << 6) /* requires UBLK_F_INTEGRITY */
+#define UBLK_PARAM_TYPE_UUID (1 << 7)
__u32 types; /* types of parameter included */
struct ublk_param_basic basic;
@@ -741,6 +746,7 @@ struct ublk_params {
struct ublk_param_dma_align dma;
struct ublk_param_segment seg;
struct ublk_param_integrity integrity;
+ struct ublk_param_uuid uuid;
};
#endif
--
2.51.0
^ permalink raw reply related
* Re: LSF/MM/BPF: 2026: Call for Proposals
From: Christian Brauner @ 2026-04-23 11:46 UTC (permalink / raw)
To: Bart Van Assche
Cc: linux-fsdevel, linux-mm, linux-block, linux-ide, linux-scsi,
linux-nvme, bpf, lsf-pc, linux-kernel
In-Reply-To: <81033e57-99e5-43f1-a6c3-c363e96f9c9f@acm.org>
On Wed, Apr 22, 2026 at 01:29:56PM -0700, Bart Van Assche wrote:
> On 1/10/26 5:24 AM, Christian Brauner wrote:
> > The annual Linux Storage, Filesystem, Memory Management, and BPF
> > (LSF/MM/BPF) Summit for 2026 will be held May 4–6, 2026 in Zagreb,
> > Croatia.
> >
> > LSF/MM/BPF is an invitation-only technical workshop to map out
> > improvements to the Linux storage, filesystem, BPF, and memory
> > management subsystems that will make their way into the mainline
> > kernel within the coming years.
> >
> > LSF/MM/BPF 2026 will be a three-day, stand-alone conference with four
> > subsystem-specific tracks, cross-track discussions, as well as BoF and
> > hacking sessions. Please check out:
> >
> > https://events.linuxfoundation.org/lsfmmbpf/
> >
> > for further details on the venue and hotels.
>
> Thank you Christian for being one of the organizers of the
> LSF/MM/BPF summit. Will a schedule be made available before the summit
> starts? A link to the 2024 schedule is available at
> https://lore.kernel.org/all/20240510212132.83346-1-sj@kernel.org/.
The preliminary schedule is accessible here:
https://docs.google.com/spreadsheets/d/1mGEdDrWskp7Ua91jGXzquQGinorcD58DAVXhOiRp2Gg/edit?gid=1852749899#gid=1852749899
It just hasn't been liked on the website yet.
^ permalink raw reply
* Re: [PATCH] block: fix deadlock between blk_mq_freeze_queue and blk_mq_dispatch_list
From: Michael Wu @ 2026-04-23 11:28 UTC (permalink / raw)
To: Ming Lei; +Cc: linux-block, linux-kernel, axboe
In-Reply-To: <5fec2f0f-97e5-2c7a-73bd-ad2ad95f2e1d@allwinnertech.com>
I apologize that due to some special circumstances, I was unable to
receive your reply via email. Therefore, I am replying to you via this
email.
I have verified that the patch you modified does indeed resolve the
aforementioned issue. To verify this, I conducted scenario verification
and Mokey stress testing on my platform.
So, should we choose the current solution as the final solution?
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b7f77c165a6e..4217aaaa8e47 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6966,7 +6966,9 @@ static inline void sched_submit_work(struct
task_struct *tsk)
* If we are going to sleep and we have plugged IO queued,
* make sure to submit it to avoid deadlocks.
*/
+ preempt_disable_notrace();
blk_flush_plug(tsk->plug, true);
+ preempt_enable_no_resched_notrace();
lock_map_release(&sched_map);
}
On 2026/4/20 14:31, Michael Wu wrote:
> I'd like to add some important information:
>
> The three processes I mentioned—Task 1838 (Back-P10-3), Task 619
> (android.hardwar), and Task 1865 (sp-control-1)—are all in an
> uninterruptible sleep state. Therefore, once Task 1865 (sp-control-1) is
> scheduled out using `preempt_schedule_notrace`, it cannot be scheduled
> back. The reason Task 1865 (sp-control-1) is in an uninterruptible sleep
> state is because `down_write` is waiting for `io_rwsem`.
>
> My analysis of the upstream kernel code doesn't seem to have found a fix
> for this issue. This situation should theoretically exist, but I don't
> have a platform to test this low-probability behavior. However, it's
> certain that this situation occurs during I/O scheduling algorithm
> switching and concurrent F2FS write operations.
>
> In this situation, `io_schedule_prepare` is not used. The path used in
> Task 1865 is
> `schedule->sched_submit_work->blk_flush_plug->blk_mq_dispatch_list`.
>
> As you said, this method is indeed not good, but I don't have a better
> idea to handle this deadlock situation.
>
> On 2026/4/17 16:27, Michael Wu wrote:
>> Kernel: Linux version 6.18.16
>> Platform: Android
>>
>> A three-way deadlock can occur between blk_mq_freeze_queue and
>> blk_mq_dispatch_list involving percpu_ref reference counting and rwsem
>> synchronization:
>>
>> - Task A holds io_rwsem (e.g., F2FS write path) and enters
>> __bio_queue_enter(),
>> where it acquires percpu_ref and waits for mq_freeze_depth==0
>> - Task B holds mq_freeze_depth=1 (elevator_change) and waits for
>> q_usage_counter to reach zero in blk_mq_freeze_queue_wait()
>> - Task C is scheduled out via schedule() while waiting for io_rwsem.
>> Before switching, __blk_flush_plug() triggers blk_mq_dispatch_list()
>> which acquires percpu_ref via percpu_ref_get(). If
>> preempt_schedule_notrace()
>> is triggered before percpu_ref_put(), Task C holds the reference while
>> blocked on the rwsem.
>>
>> Since Task C cannot release its percpu_ref while blocked, Task B cannot
>> unfreeze the queue, and Task A cannot proceed to release the io_rwsem,
>> creating a circular dependency deadlock.
>>
>> Change:
>> Fix by disabling preemption in blk_mq_dispatch_list() when called from
>> schedule() (from_sched=true), ensuring percpu_ref_get() and
>> percpu_ref_put()
>> are atomic with respect to context switches. With from_sched=true,
>> blk_mq_run_hw_queue() dispatches asynchronously via kblockd, so no driver
>> callbacks run in this context and preempt_disable() is safe.
>>
>> Detailed scenario description:
>> When process 1838 performs f2fs_submit_page_write, it obtains io_rwsem
>> via
>> f2fs_down_write_trace. When process 1865 performs
>> f2fs_down_write_trace and
>> wants to obtain io_rwsem, it needs to wait for process 1838 to release
>> it,
>> so it can only be scheduled out via schedule. Before being scheduled out,
>> it clears the plug via __blk_flush_plug, so it will run to
>> blk_mq_dispatch_list.
>> Process 619 is modifying the I/O scheduling algorithm, calling
>> elevator_change
>> to set mq_freeze_depth=1. After that, blk_mq_freeze_queue_wait will
>> wait for
>> the reference count of q_usage_counter to return to zero. Coincidentally,
>> process 1838 needs to wait for mq_freeze_depth=0 when it reaches
>> __bio_queue_enter, so it can only wait to be woken up after
>> q_freeze_depth=0.
>> At this time, process 1865, when blk_mq_dispatch_list reaches the
>> point where
>> percpu_ref_get increments the q_usage_counter reference, and before
>> percpu_ref_put, it calls preempt_schedule_notrace to schedule the
>> process out
>> due to preemption, causing q_usage_counter to never reach zero.
>>
>> At this point, process 1865 depends on io_rwsem to wake up, process 1838
>> depends on mq_freeze_depth=0 to wake up, and process 619 depends on
>> q_usage_counter being zero to wake up and unfreeze (setting
>> mq_freeze_depth=0),
>> resulting in a deadlock between these three processes.
>>
>> Stack traces from the deadlock:
>>
>> Task 1838 (Back-P10-3) - holds io_rwsem, waiting for queue unfreeze:
>> Call trace:
>> __switch_to+0x1a4/0x35c
>> __schedule+0x8e0/0xec4
>> schedule+0x54/0xf8
>> __bio_queue_enter+0xbc/0x19c
>> blk_mq_submit_bio+0x118/0x814
>> __submit_bio+0x9c/0x234
>> submit_bio_noacct_nocheck+0x10c/0x2d4
>> submit_bio_noacct+0x354/0x544
>> submit_bio+0x1e8/0x208
>> f2fs_submit_write_bio+0x44/0xe4
>> __submit_merged_bio+0x40/0x114
>> f2fs_submit_page_write+0x3f0/0x7e0
>> do_write_page+0x180/0x2fc
>> f2fs_outplace_write_data+0x78/0x100
>> f2fs_do_write_data_page+0x3b8/0x500
>> f2fs_write_single_data_page+0x1ac/0x6e0
>> f2fs_write_data_pages+0x838/0xdfc
>> do_writepages+0xd0/0x19c
>> filemap_write_and_wait_range+0x204/0x274
>> f2fs_commit_atomic_write+0x54/0x960
>> __f2fs_ioctl+0x2128/0x42c8
>> f2fs_ioctl+0x38/0xb4
>> __arm64_sys_ioctl+0xa0/0xf4
>>
>> Task 619 (android.hardwar) - holds mq_freeze_depth=1, waiting for
>> percpu_ref:
>> Call trace:
>> __switch_to+0x1a4/0x35c
>> __schedule+0x8e0/0xec4
>> schedule+0x54/0xf8
>> blk_mq_freeze_queue_wait+0x68/0xb0
>> blk_mq_freeze_queue_nomemsave+0x68/0x7c
>> elevator_change+0x70/0x14c
>> elv_iosched_store+0x1b0/0x234
>> queue_attr_store+0xe0/0x134
>> sysfs_kf_write+0x98/0xbc
>> kernfs_fop_write_iter+0x118/0x1e8
>> vfs_write+0x2e8/0x448
>> ksys_write+0x78/0xf0
>> __arm64_sys_write+0x1c/0x2c
>>
>> Task 1865 (sp-control-1) - holds percpu_ref, preempted in dispatch_list:
>> Call trace:
>> __switch_to+0x1a4/0x35c
>> __schedule+0x8e0/0xec4
>> preempt_schedule_notrace+0x60/0x7c
>> blk_mq_dispatch_list+0x5c0/0x690
>> blk_mq_flush_plug_list+0x13c/0x170
>> __blk_flush_plug+0x11c/0x17c
>> schedule+0x40/0xf8
>> schedule_preempt_disabled+0x24/0x40
>> rwsem_down_write_slowpath+0x61c/0xc88
>> down_write+0x3c/0x158
>> f2fs_down_write_trace+0x30/0x84
>> f2fs_submit_page_write+0x78/0x7e0
>> do_write_page+0x180/0x2fc
>> f2fs_outplace_write_data+0x78/0x100
>> f2fs_do_write_data_page+0x3b8/0x500
>> f2fs_write_single_data_page+0x1ac/0x6e0
>> f2fs_write_data_pages+0x838/0xdfc
>> do_writepages+0xd0/0x19c
>> filemap_write_and_wait_range+0x204/0x274
>> f2fs_commit_atomic_write+0x54/0x960
>> __f2fs_ioctl+0x2128/0x42c8
>> f2fs_ioctl+0x38/0xb4
>> __arm64_sys_ioctl+0xa0/0xf4
>>
>> Signed-off-by: Michael Wu <michael@allwinnertech.com>
>> ---
>> block/blk-mq.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/block/blk-mq.c b/block/blk-mq.c
>> index 4c5c16cce4f8f..c290bb12c1ecb 100644
>> --- a/block/blk-mq.c
>> +++ b/block/blk-mq.c
>> @@ -2936,6 +2936,14 @@ static void blk_mq_dispatch_list(struct rq_list
>> *rqs, bool from_sched)
>> *rqs = requeue_list;
>> trace_block_unplug(this_hctx->queue, depth, !from_sched);
>> + /*
>> + * When called from schedule(), prevent preemption and interrupts
>> between
>> + * ref_get and ref_put. This ensures percpu_ref_get() and
>> percpu_ref_put()
>> + * are atomic with respect to context switches, avoiding a
>> deadlock with
>> + * blk_mq_freeze_queue where a blocked task holds a percpu_ref
>> reference.
>> + */
>> + if (from_sched)
>> + local_irq_disable();
>> percpu_ref_get(&this_hctx->queue->q_usage_counter);
>> /* passthrough requests should never be issued to the I/O
>> scheduler */
>> if (is_passthrough) {
>> @@ -2951,6 +2959,8 @@ static void blk_mq_dispatch_list(struct rq_list
>> *rqs, bool from_sched)
>> blk_mq_insert_requests(this_hctx, this_ctx, &list, from_sched);
>> }
>> percpu_ref_put(&this_hctx->queue->q_usage_counter);
>> + if (from_sched)
>> + local_irq_enable();
>> }
>> static void blk_mq_dispatch_multiple_queue_requests(struct rq_list
>> *rqs)
>
--
Regards,
Michael Wu
^ permalink raw reply related
* Re: [PATCH v2] floppy: fix reference leak on platform_device_register() failure
From: Jens Axboe @ 2026-04-23 11:06 UTC (permalink / raw)
To: Jiri Slaby, Denis Efremov, Greg Kroah-Hartman, linux-block,
linux-kernel, Guangshuo Li
Cc: stable
In-Reply-To: <897f442d-4e04-4b70-b716-38fd10b8af36@kernel.org>
On 4/22/26 11:11 PM, Jiri Slaby wrote:
> On 17. 04. 26, 22:39, Jens Axboe wrote:
>>
>> On Wed, 15 Apr 2026 22:57:08 +0800, Guangshuo Li wrote:
>>> When platform_device_register() fails in do_floppy_init(), the embedded
>>> struct device in floppy_device[drive] has already been initialized by
>>> device_initialize(), but the failure path jumps to out_remove_drives
>>> without dropping the device reference for the current drive.
>>>
>>> Previously registered floppy devices are cleaned up in out_remove_drives,
>>> but the device for the drive that fails registration is not, leading to
>>> a reference leak.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [1/1] floppy: fix reference leak on platform_device_register() failure
>> commit: e784f2ea0b4fd0e7b70028ff8218f22456c5dcf8
>
> The patch is likely wrong. Given the pdev is static, the struct device
> has no ->release, so releasing it will trigger a warning. AFAIR, the
> consensus was to fix platform_device_register() proper.
Thanks for letting me know, I'll revert this change for now.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 0/3] ublk: fix maple tree lockdep warning and cleanup
From: Jens Axboe @ 2026-04-23 10:55 UTC (permalink / raw)
To: linux-block, Ming Lei
Cc: Caleb Sander Mateos, Liam R . Howlett, Shin'ichiro Kawasaki
In-Reply-To: <20260423033058.2805135-1-tom.leiming@gmail.com>
On Thu, 23 Apr 2026 11:30:55 +0800, Ming Lei wrote:
> Fix the lockdep warning reported by Jens when running ublk selftests
> with CONFIG_PROVE_RCU=y:
>
> lib/maple_tree.c:759 suspicious rcu_dereference_check() usage!
>
> ublk_buf_cleanup() was iterating the maple tree without holding
> mas_lock, triggering the splat from mas_find()'s internal
> rcu_dereference_check().
>
> [...]
Applied, thanks!
[1/3] ublk: fix maple tree lockdep warning in ublk_buf_cleanup
(no commit info)
[2/3] ublk: refactor common helper ublk_shmem_remove_ranges()
(no commit info)
[3/3] ublk: avoid unpinning pages under maple tree spinlock
(no commit info)
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 0/3] selftests: ublk: integrity test cleanups
From: Jens Axboe @ 2026-04-23 10:55 UTC (permalink / raw)
To: Ming Lei, Shuah Khan, Caleb Sander Mateos
Cc: linux-kernel, linux-block, linux-kselftest
In-Reply-To: <20260421200901.1528842-1-csander@purestorage.com>
On Tue, 21 Apr 2026 14:08:58 -0600, Caleb Sander Mateos wrote:
> Update test_integrity_02 to allow fio-3.42 now that it's been released.
> Add a modified version test_integrity_03 that uses auto integrity and
> avoids the newer fio requirement.
>
> Also clean up the callers of _cleanup passing an unnecessary argument.
>
> Caleb Sander Mateos (3):
> selftests: ublk: remove unused argument to _cleanup
> selftests: ublk: enable test_integrity_02.sh on fio 3.42
> selftests: ublk: add ublk auto integrity test
>
> [...]
Applied, thanks!
[1/3] selftests: ublk: remove unused argument to _cleanup
(no commit info)
[2/3] selftests: ublk: enable test_integrity_02.sh on fio 3.42
(no commit info)
[3/3] selftests: ublk: add ublk auto integrity test
(no commit info)
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2 3/3] scsi: use percpu counters for iorequest_cnt and iodone_cnt
From: Sumit Saxena @ 2026-04-23 9:40 UTC (permalink / raw)
To: Bart Van Assche
Cc: martin.petersen, axboe, linux-scsi, linux-block,
mpi3mr-linuxdrv.pdl
In-Reply-To: <c6a6733e-a652-40a5-8ff3-bc69e3e80102@acm.org>
[-- Attachment #1: Type: text/plain, Size: 145 bytes --]
> Why "snprintf(buf, 20, ...)"? New code should use sysfs_emit(buf, ...),
> isn't it?
Yes, I will handle it in the next revision.
Thanks,
Sumit
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]
^ permalink raw reply
* Re: [LSF/MM/BPF ATTEND][LSF/MM/BPF TOPIC] : blktests: status, expansion plan for the storage stack test framework
From: Daniel Wagner @ 2026-04-23 9:36 UTC (permalink / raw)
To: Nilay Shroff
Cc: Shin'ichiro Kawasaki, Chaitanya Kulkarni,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvme@lists.infradead.org, lsf-pc@lists.linux-foundation.org,
Bart Van Assche, Hannes Reinecke, hch, Jens Axboe,
sagi@grimberg.me, tytso@mit.edu, Johannes Thumshirn,
Christian Brauner, Martin K. Petersen,
linux-fsdevel@vger.kernel.org, Javier González,
willy@infradead.org, Jan Kara, amir73il@gmail.com, vbabka@suse.cz,
Damien Le Moal
In-Reply-To: <d6282aa7-4673-4bae-a0ff-fbd84f0a610f@linux.ibm.com>
On Thu, Apr 23, 2026 at 01:35:47PM +0530, Nilay Shroff wrote:
> > Taking this chance, I'd like to express my appreciation for the effort to
> > resolve the lockdep issues. It is great that a number of lockdeps are already
> > fixed. Said that, two lockdep issues are still observed with v7.0 kernel at
> > nvme/005 and nbd/002 [1]. I would like to gather attentions to the failures.
> >
> > [1] https://lore.kernel.org/linux-block/ynmi72x5wt5ooljjafebhcarit3pvu6axkslqenikb2p5txe57@ldytqa2t4i2x/
> >
> I think nvme/005 and nbd/002 failures shall be addressed with this
> patch: https://lore.kernel.org/all/20260413171628.6204-1-kch@nvidia.com/
>
> It's currently applied to nvme-7.1 and not there yet to mainline kernel.
FWIW, the nightly CI runs for nvme-cli with blktests/master and
linux/master are all green except for the above mentioned nvme/005 tcp
case. Thanks everyone for helping out!
https://github.com/linux-nvme/nvme-cli/actions/runs/24816292836
^ permalink raw reply
* Re: [PATCH v11 03/13] lib/group_cpus: Add group_mask_cpus_evenly()
From: Marco Crivellari @ 2026-04-23 8:11 UTC (permalink / raw)
To: Aaron Tomlin
Cc: James.Bottomley, MPT-FusionLinux.pdl, aacraid, akpm, axboe,
bigeasy, chandrakanth.patil, chenridong, chjohnst, frederic, hare,
hch, jinpu.wang, juri.lelli, kashyap.desai, kbusch, kch,
linux-block, linux-kernel, linux-nvme, linux-scsi, liyihang9,
longman, martin.petersen, maz, megaraidlinux.pdl, ming.lei, mingo,
mpi3mr-linuxdrv.pdl, mproche, mst, neelx, nick.lange, peterz,
ranjan.kumar, ruanjinjie, sagi, sathya.prakash, sean,
shivasharan.srikanteshwara, sreekanth.reddy, steve,
suganath-prabu.subramani, sumit.saxena, tglx, tom.leiming,
vincent.guittot, virtualization, wagi, yphbchou0911
In-Reply-To: <tfkr5mlsdzbhdzv46ookoy2e7ed2wcozuxanv4wagjf6hqb4sa@7i753lpqkxvp>
On Wed, Apr 22, 2026 at 7:47 PM Aaron Tomlin <atomlin@atomlin.com> wrote:
>
> On Mon, Apr 20, 2026 at 03:11:52PM +0200, Marco Crivellari wrote:
> > Without it, I guess the kmalloc() in `group_mask_cpus_evenly()` will
> > return ZERO_SIZE_PTR:
>
> Hi Marco,
>
> Thank you for reviewing the patch.
>
> You are correct. If numgrps is 0, __do_kmalloc_node() will
> return ZERO_SIZE_PTR.
>
> > Should this check be added or it is not needed? Or maybe rely on `ZERO_OR_NULL_PTR()` ?
>
> - File: mm/slub.c
>
> 5275 static __always_inline
> 5276 void *__do_kmalloc_node(size_t size, kmem_buckets *b, gfp_t flags, int node,
> 5277 unsigned long caller)
> 5278 {
> 5279 struct kmem_cache *s;
> 5280 void *ret;
> :
> 5289 if (unlikely(!size))
> 5290 return ZERO_SIZE_PTR;
> :
> 5298 }
>
> Regarding your suggestion: rather than relying on ZERO_OR_NULL_PTR() after
> the fact, I think it is much cleaner to just add the early exit at the very
> beginning of the function, exactly as group_cpus_evenly() does. It avoids
> the allocator path entirely.
Hi,
Cool, I think that's the right thing indeed.
Thanks!
--
Marco Crivellari
SUSE Labs
^ permalink raw reply
* Re: [LSF/MM/BPF ATTEND][LSF/MM/BPF TOPIC] : blktests: status, expansion plan for the storage stack test framework
From: Nilay Shroff @ 2026-04-23 8:05 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Daniel Wagner, Chaitanya Kulkarni, linux-block@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org,
lsf-pc@lists.linux-foundation.org, Bart Van Assche,
Hannes Reinecke, hch, Jens Axboe, sagi@grimberg.me, tytso@mit.edu,
Johannes Thumshirn, Christian Brauner, Martin K. Petersen,
linux-fsdevel@vger.kernel.org, Javier González,
willy@infradead.org, Jan Kara, amir73il@gmail.com, vbabka@suse.cz,
Damien Le Moal
In-Reply-To: <aecTw6IYs1fo26EX@shinmob>
On 4/21/26 11:49 AM, Shin'ichiro Kawasaki wrote:
> On Feb 16, 2026 / 00:08, Nilay Shroff wrote:
>>
>>
>> On 2/13/26 4:53 PM, Shinichiro Kawasaki wrote:
>>> On Feb 12, 2026 / 08:52, Daniel Wagner wrote:
>>>> On Wed, Feb 11, 2026 at 08:35:30PM +0000, Chaitanya Kulkarni wrote:
>>>>> For the storage track at LSFMMBPF2026, I propose a session dedicated to
>>>>> blktests to discuss expansion plan and CI integration progress.
>>>>
>>>> Thanks for proposing this topic.
>>>
>>> Chaitanya, my thank also goes to you.
>>>
>> Yes thanks for proposing this!
>>
>>>> Just a few random topics which come to mind we could discuss:
>>>>
>>>> - blktests has gain a bit of traction and some folks run on regular
>>>> basis these tests. Can we gather feedback from them, what is working
>>>> good, what is not? Are there feature wishes?
>>>
>>> Good topic, I also would like to hear about it.
>>>
>> One improvement I’d like to highlight is related to how blktests are executed
>> today. So far, we’ve been running blktests serially, but if it's possible to
>> run tests in parallel to improve test turnaround time and make large-scale or
>> CI-based testing more efficient? For instance, adding parallel_safe Tags: Marking tests
>> that don't modify global kernel state so they can be safely offloaded to parallel
>> workers. Marking parallel_safe tags would allow the runner to distinguish:
>>
>> Safe Tests: Tests that only perform I/O on a specific, non-shared device or
>> check static kernel parameters.
>>
>> Unsafe Tests: Tests that reload kernel modules, modify global /sys or /proc entries,
>> or require exclusive access to specific hardware addresses.
>>
>> Yes adding parallel execution support shall require framework/design changes.
>
> Hi Nilay, thanks for the idea. I understand that shorter test time will make CI
> cycles faster and improve the development efficiency.
>
> Said that, the safe/unsafe testing idea may not be enough. I think majority of
> test case does kernel module set up using null_blk, scsi_debug, or nvme target
> drivers. Then I foresee the majority of the test cases will be "unsafe", and
> cannot be run in parallel.
>
> Also, parallel runs on single system will affect dmesg or kmemleak checking.
> We cannot tell which run caused a dmesg message or a memory leak.
>
> For the runtime reduction by parallel runs, I guess blktests run on VMs might be
> the good approach as Haris pointed out. Anyway, this topic will need more
> discussion.
>
> [...]
Alright, see if we may discuss this during LSFMM.
>
>>> 4. Long standing failures make test result reports dirty
>>> - I feel lockdep WARNs are tend to be left unfixed rather long period.
>>> How can we gather effort to fix them?
>>
>> I agree regarding lockdep; recently we did see quite a few lockdep splats.
>> That said, I believe the number has dropped significantly and only a small
>> set remains. From what I can tell, most of the outstanding lockdep issues
>> are related to fs-reclaim paths recursing into the block layer while the
>> queue is frozen. We should be able to resolve most of these soon, or at
>> least before the conference. If anything is still outstanding after that,
>> we can discuss it during the conference and work toward addressing it as
>> quickly as possible.
>
> Taking this chance, I'd like to express my appreciation for the effort to
> resolve the lockdep issues. It is great that a number of lockdeps are already
> fixed. Said that, two lockdep issues are still observed with v7.0 kernel at
> nvme/005 and nbd/002 [1]. I would like to gather attentions to the failures.
>
> [1] https://lore.kernel.org/linux-block/ynmi72x5wt5ooljjafebhcarit3pvu6axkslqenikb2p5txe57@ldytqa2t4i2x/
>
I think nvme/005 and nbd/002 failures shall be addressed with this
patch: https://lore.kernel.org/all/20260413171628.6204-1-kch@nvidia.com/
It's currently applied to nvme-7.1 and not there yet to mainline kernel.
Thanks,
--Nilay
^ permalink raw reply
* Re: [PATCH v6 01/43] fscrypt: add per-extent encryption support
From: Daniel Vacek @ 2026-04-23 6:45 UTC (permalink / raw)
To: Eric Biggers
Cc: Chris Mason, Josef Bacik, Theodore Y. Ts'o, Jaegeuk Kim,
Jens Axboe, David Sterba, linux-block, linux-fscrypt, linux-btrfs,
linux-kernel
In-Reply-To: <20260422225310.GB2226@sol>
On Thu, 23 Apr 2026 at 00:54, Eric Biggers <ebiggers@kernel.org> wrote:
> On Wed, Apr 22, 2026 at 10:17:40AM +0200, Daniel Vacek wrote:
> > > > +/**
> > > > + * fscrypt_mergeable_extent_bio() - test whether data can be added to a bio
> > > > + * @bio: the bio being built up
> > > > + * @ei: the fscrypt_extent_info for this extent
> > > > + * @next_lblk: the next file logical block number in the I/O
> > > > + *
> > > > + * When building a bio which may contain data which should undergo inline
> > > > + * encryption (or decryption) via fscrypt, filesystems should call this function
> > > > + * to ensure that the resulting bio contains only contiguous data unit numbers.
> > > > + * This will return false if the next part of the I/O cannot be merged with the
> > > > + * bio because either the encryption key would be different or the encryption
> > > > + * data unit numbers would be discontiguous.
> > > > + *
> > > > + * fscrypt_set_bio_crypt_ctx_from_extent() must have already been called on the
> > > > + * bio.
> > > > + *
> > > > + * This function isn't required in cases where crypto-mergeability is ensured in
> > > > + * another way, such as I/O targeting only a single file (and thus a single key)
> > > > + * combined with fscrypt_limit_io_blocks() to ensure DUN contiguity.
> > > > + *
> > > > + * Return: true iff the I/O is mergeable
> > > > + */
> > > > +bool fscrypt_mergeable_extent_bio(struct bio *bio,
> > > > + const struct fscrypt_extent_info *ei,
> > > > + u64 next_lblk)
> > > > +{
> > > > + const struct bio_crypt_ctx *bc = bio->bi_crypt_context;
> > > > + u64 next_dun[BLK_CRYPTO_DUN_ARRAY_SIZE] = { next_lblk };
> > > > +
> > > > + if (!ei)
> > > > + return true;
> > > > + if (!bc)
> > > > + return true;
> > > > +
> > > > + /*
> > > > + * Comparing the key pointers is good enough, as all I/O for each key
> > > > + * uses the same pointer. I.e., there's currently no need to support
> > > > + * merging requests where the keys are the same but the pointers differ.
> > > > + */
> > > > + if (bc->bc_key != ei->prep_key.blk_key)
> > > > + return false;
> > > > +
> > > > + return bio_crypt_dun_is_contiguous(bc, bio->bi_iter.bi_size, next_dun);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(fscrypt_mergeable_extent_bio);
> > >
> > > Similar to fscrypt_set_bio_crypt_ctx_from_extent(). The copy-pasted
> > > comment needs to be updated to remove no-longer-relevant information
> > > specific to per-file encryption and correctly reflect per-extent
> > > encryption. The DUN needs to be calculated correctly for sub-block data
> > > units or else the combination of the two needs to be unsupported.
> >
> > The DUN is fixed as per above. Regarding the comment, it looks quite
> > valid to me. What exactly would you like to change?
>
> It's now been a while since I was looking at this, but looking at it
> again now, at least the following parts are incorrect:
>
> "the next file logical block number in the I/O"
>
> "I/O targeting only a single file (and thus a single key)"
>
> It's actually the block number in the *extent*. And it's a single key
> only when the I/O targets a single *extent*.
Yeah, I fixed the block number comment with the change to the `pos`
offset. That one is clear.
I'll amend the rest.
Thank you very much, Eric.
--nX
> - Eric
^ permalink raw reply
* Re: [PATCH v2] floppy: fix reference leak on platform_device_register() failure
From: Jiri Slaby @ 2026-04-23 5:11 UTC (permalink / raw)
To: Jens Axboe, Denis Efremov, Greg Kroah-Hartman, linux-block,
linux-kernel, Guangshuo Li
Cc: stable
In-Reply-To: <177645836617.906013.5675762942401997007.b4-ty@b4>
On 17. 04. 26, 22:39, Jens Axboe wrote:
>
> On Wed, 15 Apr 2026 22:57:08 +0800, Guangshuo Li wrote:
>> When platform_device_register() fails in do_floppy_init(), the embedded
>> struct device in floppy_device[drive] has already been initialized by
>> device_initialize(), but the failure path jumps to out_remove_drives
>> without dropping the device reference for the current drive.
>>
>> Previously registered floppy devices are cleaned up in out_remove_drives,
>> but the device for the drive that fails registration is not, leading to
>> a reference leak.
>>
>> [...]
>
> Applied, thanks!
>
> [1/1] floppy: fix reference leak on platform_device_register() failure
> commit: e784f2ea0b4fd0e7b70028ff8218f22456c5dcf8
The patch is likely wrong. Given the pdev is static, the struct device
has no ->release, so releasing it will trigger a warning. AFAIR, the
consensus was to fix platform_device_register() proper.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH 3/3] selftests: ublk: add ublk auto integrity test
From: Ming Lei @ 2026-04-23 3:57 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Shuah Khan, linux-kernel, linux-block, linux-kselftest
In-Reply-To: <20260421200901.1528842-4-csander@purestorage.com>
On Tue, Apr 21, 2026 at 02:09:01PM -0600, Caleb Sander Mateos wrote:
> The end-to-end integrity ublk selftest test_integrity_02 requires a
> relatively recent fio version to support I/O with integrity buffers. Add
> a version test_integrity_03 that uses the block layer's auto integrity
> path instead. The auto integrity code doesn't check the application tag,
> and doesn't indicate the bad guard/ref tag (just returns EILSEQ). But
> it's a good smoke-test of the ublk integrity code and provides coverage
> of the auto integrity path as well.
>
> Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH 2/3] selftests: ublk: enable test_integrity_02.sh on fio 3.42
From: Ming Lei @ 2026-04-23 3:57 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Shuah Khan, linux-kernel, linux-block, linux-kselftest
In-Reply-To: <20260421200901.1528842-3-csander@purestorage.com>
On Tue, Apr 21, 2026 at 02:09:00PM -0600, Caleb Sander Mateos wrote:
> fio 3.42 was released with the needed fix for test_integrity_02.sh.
> Allow 3.42 and newer in the fio version check.
>
> Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH 1/3] selftests: ublk: remove unused argument to _cleanup
From: Ming Lei @ 2026-04-23 3:56 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Shuah Khan, linux-kernel, linux-block, linux-kselftest
In-Reply-To: <20260421200901.1528842-2-csander@purestorage.com>
On Tue, Apr 21, 2026 at 02:08:59PM -0600, Caleb Sander Mateos wrote:
> The _cleanup helper function doesn't take any arguments, so drop them
> from its callers.
>
> Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH v3] Fix null-ptr-deref in bio_integrity_map_user()
From: Sungwoo Kim @ 2026-04-23 3:33 UTC (permalink / raw)
To: Jens Axboe, Keith Busch
Cc: Chao Shi, Weidong Zhu, Dave Tian, linux-block, linux-kernel
In-Reply-To: <20260420020327.1667156-3-iam@sung-woo.kim>
This is a follow-up based on Sashiko's comments.
https://sashiko.dev/#/patchset/20260420020327.1667156-3-iam%40sung-woo.kim
On Sun, Apr 19, 2026 at 10:05 PM Sungwoo Kim <iam@sung-woo.kim> wrote:
>
[snip]
> diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> index e79eaf047794..c8cfd15fb589 100644
> --- a/block/bio-integrity.c
> +++ b/block/bio-integrity.c
> @@ -402,6 +402,20 @@ int bio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
> extraction_flags, &offset);
> if (unlikely(ret < 0))
> goto free_bvec;
It's pre-existing, though, free_bvec does not kvfree(pages), leading
to a memory leak.
> + /* Handle partial pinning. This can happen when pin_user_pages_fast()
> + * returns fewer pages than requested
> + */
> + if (unlikely(ret != bytes)) {
> + int npinned = DIV_ROUND_UP(offset + ret, PAGE_SIZE);
If ret == 0, npinned becomes 1, whereas there is no actually pinned memory
> + int i;
> +
> + for (i = 0; i < npinned; i++)
> + unpin_user_page(pages[i]);
... which results in invalid access here.
Also, pages[i] can be ITER_KVEC, ITER_BVEC, ITER_FOLIOQ, etc., which
do not pin memory.
Thus, calling unpin_user_page(pages[i]) unconditionally is incorrect.
To fix this, call unpin_user_page() when user_backed_iter(iter) is true.
> + if (pages != stack_pages)
> + kvfree(pages);
> + ret = -EFAULT;
> + goto free_bvec;
> + }
>
> nr_bvecs = bvec_from_pages(bvec, pages, nr_vecs, bytes, offset,
> &is_p2p);
> --
> 2.47.3
>
^ 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