* Re: [PATCH] block: assign caller-specific lockdep class to disk->open_mutex
From: Bart Van Assche @ 2026-05-30 21:15 UTC (permalink / raw)
To: Tetsuo Handa, Jens Axboe, linux-block, LKML
Cc: Andrew Morton, Ming Lei, Damien Le Moal, Christoph Hellwig,
Qu Wenruo, Hillf Danton
In-Reply-To: <147ed056-03d9-4214-b925-0f10fc00cf27@I-love.SAKURA.ne.jp>
On 5/30/26 6:45 AM, Tetsuo Handa wrote:
> - static struct lock_class_key __key; \
> + static struct lock_class_key __key[2]; \
The two elements of this array have different roles. From the point of
view of code readability and maintainability it's probably much better
to make this a struct with two named members rather than a two-element
array.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH] block: assign caller-specific lockdep class to disk->open_mutex
From: Hillf Danton @ 2026-05-30 22:50 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Jens Axboe, linux-block, LKML, Bart Van Assche, Boqun Feng,
Andrew Morton, Ming Lei, Damien Le Moal, Christoph Hellwig,
Qu Wenruo, Hillf Danton
In-Reply-To: <147ed056-03d9-4214-b925-0f10fc00cf27@I-love.SAKURA.ne.jp>
On Sat, 30 May 2026 22:45:55 +0900 Tetsuo Handa wrote:
> The block core currently allocates a single monolithic lockdep key for
> disk->open_mutex across all callers. This single key conflates locking
> hierarchies between independent block streams. For example, if a stacked
> driver like loop flushes its internal workqueues inside lo_release() while
> holding its own open_mutex, lockdep views this as a potential ABBA deadlock
> against the underlying storage stack, leading to numerous circular
> dependency splats [2][3][4][5][6].
>
> To reduce false-positives structurally, this patch splits the global
> monolithic lock class into distinct, per-caller during disk allocation;
> by changing "lock_class_key" into a 2-element array:
> - lkclass[0]: Used for the legacy "(bio completion)" map.
> - lkclass[1]: Assigned to target caller's disk->open_mutex.
>
I wonder how this works given e966eaeeb623 ("locking/lockdep: Remove the
cross-release locking checks").
> This patch was tested by adding drain_workqueue() to __loop_clr_fd() during
> testing of a patch for [1], and actually helped stopping [2][4][6].
> Even if our final solution for [1] does not call drain_workqueue() with
> disk->open_mutex held, keeping locking chains simpler and shorter should
> be a good change.
>
> Link: https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28 [1]
> Link: https://syzkaller.appspot.com/bug?extid=2f62807dc3239b8f584e [2]
> Link: https://syzkaller.appspot.com/bug?extid=c4e9d077bcc86bee08dc [3]
> Link: https://syzkaller.appspot.com/bug?extid=0f427123ae84b3ba6dc7 [4]
> Link: https://syzkaller.appspot.com/bug?extid=4feabfc9641267769c97 [5]
> Link: https://syzkaller.appspot.com/bug?extid=fb0ff9bfe34ad282ebd4 [6]
> Suggested-by: AI Mode in Google Search (no mail address)
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> block/blk-mq.c | 4 ++--
> block/blk.h | 2 +-
> block/genhd.c | 8 ++++----
> drivers/scsi/sd.c | 4 ++--
> drivers/scsi/sr.c | 4 ++--
> include/linux/blk-mq.h | 8 ++++----
> include/linux/blkdev.h | 6 +++---
> 7 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 28c2d931e75e..01a15ac40754 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -4492,7 +4492,7 @@ EXPORT_SYMBOL(blk_mq_destroy_queue);
>
> struct gendisk *__blk_mq_alloc_disk(struct blk_mq_tag_set *set,
> struct queue_limits *lim, void *queuedata,
> - struct lock_class_key *lkclass)
> + struct lock_class_key lkclass[2])
> {
> struct request_queue *q;
> struct gendisk *disk;
> @@ -4513,7 +4513,7 @@ struct gendisk *__blk_mq_alloc_disk(struct blk_mq_tag_set *set,
> EXPORT_SYMBOL(__blk_mq_alloc_disk);
>
> struct gendisk *blk_mq_alloc_disk_for_queue(struct request_queue *q,
> - struct lock_class_key *lkclass)
> + struct lock_class_key lkclass[2])
> {
> struct gendisk *disk;
>
> diff --git a/block/blk.h b/block/blk.h
> index b998a7761faf..1744748f9b68 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -614,7 +614,7 @@ void drop_partition(struct block_device *part);
> void bdev_set_nr_sectors(struct block_device *bdev, sector_t sectors);
>
> struct gendisk *__alloc_disk_node(struct request_queue *q, int node_id,
> - struct lock_class_key *lkclass);
> + struct lock_class_key lkclass[2]);
> struct request_queue *blk_alloc_queue(struct queue_limits *lim, int node_id);
>
> int disk_scan_partitions(struct gendisk *disk, blk_mode_t mode);
> diff --git a/block/genhd.c b/block/genhd.c
> index 7d6854fd28e9..303bd5e619e7 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -1444,7 +1444,7 @@ dev_t part_devt(struct gendisk *disk, u8 partno)
> }
>
> struct gendisk *__alloc_disk_node(struct request_queue *q, int node_id,
> - struct lock_class_key *lkclass)
> + struct lock_class_key lkclass[2])
> {
> struct gendisk *disk;
>
> @@ -1467,7 +1467,7 @@ struct gendisk *__alloc_disk_node(struct request_queue *q, int node_id,
> goto out_free_bdi;
>
> disk->node_id = node_id;
> - mutex_init(&disk->open_mutex);
> + mutex_init_with_key(&disk->open_mutex, &lkclass[1]);
> xa_init(&disk->part_tbl);
> if (xa_insert(&disk->part_tbl, 0, disk->part0, GFP_KERNEL))
> goto out_destroy_part_tbl;
> @@ -1482,7 +1482,7 @@ struct gendisk *__alloc_disk_node(struct request_queue *q, int node_id,
> device_initialize(disk_to_dev(disk));
> inc_diskseq(disk);
> q->disk = disk;
> - lockdep_init_map(&disk->lockdep_map, "(bio completion)", lkclass, 0);
> + lockdep_init_map(&disk->lockdep_map, "(bio completion)", &lkclass[0], 0);
> #ifdef CONFIG_BLOCK_HOLDER_DEPRECATED
> INIT_LIST_HEAD(&disk->slave_bdevs);
> #endif
> @@ -1506,7 +1506,7 @@ struct gendisk *__alloc_disk_node(struct request_queue *q, int node_id,
> }
>
> struct gendisk *__blk_alloc_disk(struct queue_limits *lim, int node,
> - struct lock_class_key *lkclass)
> + struct lock_class_key lkclass[2])
> {
> struct queue_limits default_lim = { };
> struct request_queue *q;
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 599e75f33334..d8a1bbd4f19e 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -112,7 +112,7 @@ static DEFINE_MUTEX(sd_mutex_lock);
> static mempool_t *sd_page_pool;
> static mempool_t *sd_large_page_pool;
> static atomic_t sd_large_page_pool_users = ATOMIC_INIT(0);
> -static struct lock_class_key sd_bio_compl_lkclass;
> +static struct lock_class_key sd_bio_compl_lkclass[2];
>
> static const char *sd_cache_types[] = {
> "write through", "none", "write back",
> @@ -4021,7 +4021,7 @@ static int sd_probe(struct scsi_device *sdp)
> goto out;
>
> gd = blk_mq_alloc_disk_for_queue(sdp->request_queue,
> - &sd_bio_compl_lkclass);
> + sd_bio_compl_lkclass);
> if (!gd)
> goto out_free;
>
> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> index c36c54ecd354..421b8bd37db0 100644
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
> @@ -106,7 +106,7 @@ static struct scsi_driver sr_template = {
> static unsigned long sr_index_bits[SR_DISKS / BITS_PER_LONG];
> static DEFINE_SPINLOCK(sr_index_lock);
>
> -static struct lock_class_key sr_bio_compl_lkclass;
> +static struct lock_class_key sr_bio_compl_lkclass[2];
>
> static int sr_open(struct cdrom_device_info *, int);
> static void sr_release(struct cdrom_device_info *);
> @@ -634,7 +634,7 @@ static int sr_probe(struct scsi_device *sdev)
> goto fail;
>
> disk = blk_mq_alloc_disk_for_queue(sdev->request_queue,
> - &sr_bio_compl_lkclass);
> + sr_bio_compl_lkclass);
> if (!disk)
> goto fail_free;
> mutex_init(&cd->lock);
> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index 18a2388ba581..57d805c78827 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -726,15 +726,15 @@ enum {
>
> struct gendisk *__blk_mq_alloc_disk(struct blk_mq_tag_set *set,
> struct queue_limits *lim, void *queuedata,
> - struct lock_class_key *lkclass);
> + struct lock_class_key lkclass[2]);
> #define blk_mq_alloc_disk(set, lim, queuedata) \
> ({ \
> - static struct lock_class_key __key; \
> + static struct lock_class_key __key[2]; \
> \
> - __blk_mq_alloc_disk(set, lim, queuedata, &__key); \
> + __blk_mq_alloc_disk(set, lim, queuedata, __key); \
> })
> struct gendisk *blk_mq_alloc_disk_for_queue(struct request_queue *q,
> - struct lock_class_key *lkclass);
> + struct lock_class_key lkclass[2]);
> struct request_queue *blk_mq_alloc_queue(struct blk_mq_tag_set *set,
> struct queue_limits *lim, void *queuedata);
> int blk_mq_init_allocated_queue(struct blk_mq_tag_set *set,
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 890128cdea1c..3cd2056cde28 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -974,7 +974,7 @@ int bdev_disk_changed(struct gendisk *disk, bool invalidate);
>
> void put_disk(struct gendisk *disk);
> struct gendisk *__blk_alloc_disk(struct queue_limits *lim, int node,
> - struct lock_class_key *lkclass);
> + struct lock_class_key lkclass[2]);
>
> /**
> * blk_alloc_disk - allocate a gendisk structure
> @@ -990,9 +990,9 @@ struct gendisk *__blk_alloc_disk(struct queue_limits *lim, int node,
> */
> #define blk_alloc_disk(lim, node_id) \
> ({ \
> - static struct lock_class_key __key; \
> + static struct lock_class_key __key[2]; \
> \
> - __blk_alloc_disk(lim, node_id, &__key); \
> + __blk_alloc_disk(lim, node_id, __key); \
> })
>
> int __register_blkdev(unsigned int major, const char *name,
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH v3] loop: Fix NULL pointer dereference in lo_rw_aio()
From: Tetsuo Handa @ 2026-05-30 23:57 UTC (permalink / raw)
To: Hillf Danton, Jens Axboe
Cc: Bart Van Assche, Christoph Hellwig, Damien Le Moal, Ming Lei,
linux-block, LKML, Andrew Morton, Linus Torvalds, linux-btrfs,
David Sterba, linux-fsdevel, Christian Brauner
In-Reply-To: <20260529220600.1226-1-hdanton@sina.com>
On 2026/05/30 7:05, Hillf Danton wrote:
>>> Therefore, I think we can address this problem by "drain_workqueue() with disk->open_mutex
>>> held" in the loop driver side.
>>>
>> Good news.
>>
> Bad news: Subject: [syzbot] [block?] possible deadlock in loop_process_work
> [3] https://lore.kernel.org/lkml/6a19f5f7.5099cdd9.8e407.0004.GAE@google.com/
>
OK. I sent two patches
https://lkml.kernel.org/r/147ed056-03d9-4214-b925-0f10fc00cf27@I-love.SAKURA.ne.jp
https://lkml.kernel.org/r/148efba2-a0b6-47d7-ac76-b19d2f4b696c@I-love.SAKURA.ne.jp
as a preparation for evaluating the possibility of calling drain_workqueue() from
__loop_clr_fd(). But as far as syzbot has tested using linux-next tree
https://syzkaller.appspot.com/bug?extid=c4e9d077bcc86bee08dc
https://syzkaller.appspot.com/bug?extid=4feabfc9641267769c97
seems to remain even if we applied above patches.
Therefore, I think that we need to call drain_workqueue() from __loop_clr_fd()
without holding disk->open_mutex (if we address this NULL pointer dereference
problem by updating the loop driver).
"[PATCH v3] loop: Fix NULL pointer dereference in lo_rw_aio()" was an attempt to call
drain_workqueue() from __loop_clr_fd() without holding disk->open_mutex, but Sashiko's
review ( https://sashiko.dev/#/patchset/fda8abc8-6aa2-463b-bf72-865f6b838034%40I-love.SAKURA.ne.jp )
mentioned that the "module_put(THIS_MODULE);" executed as the last step of __loop_clr_fd() has
a race window of concurrently triggering module unload operation because module refcount of
the loop driver can become 0 due to this module_put(THIS_MODULE) call. In other words,
we cannot safely manage refcount of the loop module without a support by the caller of
lo_release() (i.e. bdev_release()).
void bdev_release(struct file *bdev_file)
{
(...snipped...)
if (bdev_is_partition(bdev))
blkdev_put_part(bdev);
else
blkdev_put_whole(bdev);
mutex_unlock(&disk->open_mutex); // <= Keeping holding disk->open_mutex until __loop_clr_fd() completes causes circular locking problem.
module_put(disk->fops->owner); // <= Calling after __loop_clr_fd() completed is required for managing module refcount safely.
put_no_open:
blkdev_put_no_open(bdev);
}
Therefore, I think that the only robust and safe approach is, although you won't be
happy to see layering violation / tricky code, either
(a) allow __loop_clr_fd() to temporarily drop disk->open_mutex
or
(b) add a new callback for the loop driver which is called between mutex_unlock(&disk->open_mutex) and module_put(disk->fops->owner)
. Jens, what do you think?
One might argue that this problem should be fixed on the filesystem side by
ensuring all filesystems wait for I/O requests safely. However, from the
perspective of defensive programming, the loop driver should be robust enough
to handle incomplete I/O serialization from underlying layers to prevent GPF.
Furthermore, without adding noisy debug printk() messages, it is extremely
difficult to pinpoint which specific layer or filesystem failed to wait for
the I/O requests.
^ permalink raw reply
* Re: [PATCH v7 00/43] btrfs: add fscrypt support
From: Eric Biggers @ 2026-05-31 0:28 UTC (permalink / raw)
To: Daniel Vacek
Cc: David Sterba, linux-block, linux-fscrypt, linux-btrfs,
linux-kernel, Chris Mason, Josef Bacik, Theodore Y. Ts'o,
Jaegeuk Kim, Jens Axboe
In-Reply-To: <CAPjX3FdHJpZUVk2dfA+Ov5K6vOSsOJMUaxCU4G8y1qg6baMXYw@mail.gmail.com>
On Fri, May 22, 2026 at 09:00:46AM +0200, Daniel Vacek wrote:
> Hi Eric,
>
> This is just a gentle ping.
> I was wondering if you had a chance to look at this version?
> I believe all your previous feedback has been addressed and this
> version is solid.
> Please, let me know your thoughts.
>
> Regards,
> Daniel
It's been really hard to find time to review this huge patchset. I've
started going through it and will try to leave comments next week.
In the mean time it would be really helpful if you went through the
Sashiko reviews
(https://sashiko.dev/#/patchset/20260513085340.3673127-1-neelx%40suse.com)
and address the ones that make sense to. It found 93 issues including
16 critical ones, which is kind of a lot. Some of them are the same
things I'm noticing already. Same for the issue that Christoph noticed
where new devices can be added; Sashiko had already found that too.
If I'm going to have to use my limited human review time to point out
issues that were already found, that's not a great use of time.
I also don't see any information about how this was tested (and will
continue to be tested in the future).
- Eric
^ permalink raw reply
* [syzbot] [block?] general protection fault in ublk_queue_rq
From: syzbot @ 2026-05-31 1:20 UTC (permalink / raw)
To: axboe, linux-block, linux-kernel, syzkaller-bugs, tom.leiming
Hello,
syzbot found the following issue on:
HEAD commit: 4b4362973b6f Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=165f17a6580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f52fb4a6d220c448
dashboard link: https://syzkaller.appspot.com/bug?extid=415b9ec753cd2a196087
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
userspace arch: arm64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15a33a0e580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=115f17a6580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/cdc9dd8cab69/disk-4b436297.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6bb74747f86d/vmlinux-4b436297.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a20d7153214f/Image-4b436297.gz.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+415b9ec753cd2a196087@syzkaller.appspotmail.com
Unable to handle kernel paging request at virtual address dfff800000000003
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
Mem abort info:
ESR = 0x0000000096000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
Data abort info:
ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[dfff800000000003] address between user and kernel address ranges
Internal error: Oops: 0000000096000005 [#1] SMP
Modules linked in:
CPU: 0 UID: 0 PID: 4778 Comm: kworker/0:3 Not tainted syzkaller #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Workqueue: events ublk_partition_scan_work
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : ublk_queue_cmd drivers/block/ublk_drv.c:2095 [inline]
pc : ublk_queue_rq+0x114/0x1dc drivers/block/ublk_drv.c:2223
lr : ublk_queue_cmd drivers/block/ublk_drv.c:2092 [inline]
lr : ublk_queue_rq+0xec/0x1dc drivers/block/ublk_drv.c:2223
sp : ffff800099646b10
x29: ffff800099646b20 x28: ffff7000132c8d80 x27: ffff0000c610b280
x26: ffff0000c610b2c8 x25: 1fffe00018c21652 x24: dfff800000000000
x23: 0000000000000004 x22: 0000000000000002 x21: 0000000000000000
x20: ffff0000c610b280 x19: 0000000000000000 x18: 00000000ffffffff
x17: ffff80008a186c80 x16: ffff80008a4b54f8 x15: ffff0000d9c0c550
x14: ffff0000d9c0c530 x13: 0000000000000001 x12: 0000000000000000
x11: ffff80008a3fcd08 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000003 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000008 x3 : ffff800082559f20
x2 : 0000000000000004 x1 : ffff0000d9c0ba00 x0 : 0000000000000018
Call trace:
ublk_queue_cmd drivers/block/ublk_drv.c:2095 [inline] (P)
ublk_queue_rq+0x114/0x1dc drivers/block/ublk_drv.c:2223 (P)
blk_mq_dispatch_rq_list+0x3bc/0x13a4 block/blk-mq.c:2148
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xa40/0x10bc block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xa4/0x154 block/blk-mq-sched.c:329
blk_mq_run_hw_queue+0x3c0/0x4dc block/blk-mq.c:2386
blk_mq_dispatch_list+0xa2c/0xb2c block/blk-mq.c:-1
blk_mq_flush_plug_list+0x3a4/0x484 block/blk-mq.c:2997
__blk_flush_plug+0x338/0x410 block/blk-core.c:1230
blk_finish_plug block/blk-core.c:1257 [inline]
__submit_bio+0x39c/0x478 block/blk-core.c:649
__submit_bio_noacct_mq block/blk-core.c:722 [inline]
submit_bio_noacct_nocheck+0x284/0xa98 block/blk-core.c:753
submit_bio_noacct+0xd90/0x1814 block/blk-core.c:884
submit_bio+0x38c/0x528 block/blk-core.c:926
blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline]
submit_bh_wbc+0x4b0/0x594 fs/buffer.c:2737
submit_bh fs/buffer.c:2742 [inline]
block_read_full_folio+0x69c/0x734 fs/buffer.c:2358
blkdev_read_folio+0x28/0x38 block/fops.c:494
filemap_read_folio+0xf0/0x2fc mm/filemap.c:2502
do_read_cache_folio+0x368/0x5b8 mm/filemap.c:4107
read_cache_folio+0x68/0x84 mm/filemap.c:4139
read_mapping_folio include/linux/pagemap.h:1017 [inline]
read_part_sector+0xcc/0x708 block/partitions/core.c:724
adfspart_check_ICS+0xa4/0x6fc block/partitions/acorn.c:356
check_partition block/partitions/core.c:143 [inline]
blk_add_partitions block/partitions/core.c:591 [inline]
bdev_disk_changed+0x6fc/0x11c8 block/partitions/core.c:695
ublk_partition_scan_work+0x74/0xf4 drivers/block/ublk_drv.c:2467
process_one_work kernel/workqueue.c:3314 [inline]
process_scheduled_works+0x79c/0x1098 kernel/workqueue.c:3397
worker_thread+0x754/0xba0 kernel/workqueue.c:3478
kthread+0x2f8/0x3c8 kernel/kthread.c:436
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:842
Code: 979832c3 f94002b5 910062a0 d343fc08 (38786908)
---[ end trace 0000000000000000 ]---
----------------
Code disassembly (best guess):
0: 979832c3 bl 0xfffffffffe60cb0c
4: f94002b5 ldr x21, [x21]
8: 910062a0 add x0, x21, #0x18
c: d343fc08 lsr x8, x0, #3
* 10: 38786908 ldrb w8, [x8, x24] <-- trapping instruction
---
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 syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
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: [PATCH] block: blk-zoned: fix zwplug refcount leak on write error path
From: kernel test robot @ 2026-05-31 8:44 UTC (permalink / raw)
To: Wentao Liang
Cc: oe-lkp, lkp, linux-block, Jens Axboe, Damien Le Moal,
linux-kernel, Wentao Liang, stable, oliver.sang
In-Reply-To: <20260526141824.2293025-1-vulab@iscas.ac.cn>
Hello,
kernel test robot noticed "RIP:disk_free_zone_wplug" on:
commit: d9343256aa173471dbb7f3e02a2177801f2f2136 ("[PATCH] block: blk-zoned: fix zwplug refcount leak on write error path")
url: https://github.com/intel-lab-lkp/linux/commits/Wentao-Liang/block-blk-zoned-fix-zwplug-refcount-leak-on-write-error-path/20260526-234750
base: https://git.kernel.org/cgit/linux/kernel/git/axboe/linux.git for-next
patch link: https://lore.kernel.org/all/20260526141824.2293025-1-vulab@iscas.ac.cn/
patch subject: [PATCH] block: blk-zoned: fix zwplug refcount leak on write error path
in testcase: blktests
version: blktests-x86_64-9131687-1_20260529
with following parameters:
test: zbd-004
config: x86_64-rhel-9.4-func
compiler: gcc-14
test machine: 16 threads Intel(R) Core(TM) i7-13620H (Raptor Lake) with 32G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202605311048.34c03950-lkp@intel.com
[ 38.687737][ T420] INFO: lkp CACHE_DIR is /opt/rootfs/tmp
[ 38.687747][ T420]
[ 40.261858][ T1207] loop: module loaded
[ 40.340461][ T1252] null_blk: disk nullb0 created
[ 40.341026][ T1252] null_blk: module loaded
[ 40.347691][ T1255] null_blk: nullb1: using native zone append
[ 40.349880][ T1255] null_blk: disk nullb1 created
[ 40.402539][ T1255] run blktests zbd/004 at 2026-05-30 10:54:31
[ 40.445801][ T1286] ------------[ cut here ]------------
[ 40.446398][ T1286] WARNING: block/blk-zoned.c:590 at disk_free_zone_wplug+0x26b/0x330, CPU#3: dd/1286
[ 40.447008][ T1286] Modules linked in: null_blk loop btrfs libblake2b zstd_compress raid6_pq xor binfmt_misc snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_hda_codec_alc269 snd_hda_codec_realtek_lib snd_hda_scodec_component snd_hda_codec_generic snd_hda_intel snd_sof_pci_intel_tgl snd_sof_pci_intel_cnl snd_sof_intel_hda_generic soundwire_intel snd_sof_intel_hda_sdw_bpt snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda_mlink snd_sof_intel_hda soundwire_cadence intel_rapl_msr snd_sof_pci snd_sof_xtensa_dsp snd_soc_sdw_utils intel_uncore_frequency intel_uncore_frequency_common x86_pkg_temp_thermal snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi_intel_sdca_quirks soundwire_generic_allocation snd_soc_acpi crc8 soundwire_bus snd_soc_sdca intel_powerclamp coretemp snd_soc_avs snd_soc_hda_codec snd_hda_ext_core spi_pxa2xx_platform snd_hda_codec dw_dmac kvm_intel snd_hda_core spi_pxa2xx_core i915 snd_intel_dspcfg snd_intel_sdw_acpi processor_thermal_device_pci snd_hwdep processor_thermal_device kvm intel_gtt
[ 40.447061][ T1286] processor_thermal_wt_hint drm_buddy snd_soc_core ttm btusb platform_temperature_control iwlwifi btrtl snd_compress processor_thermal_soc_slider drm_display_helper spi_nor btintel processor_thermal_rfim snd_pcm irqbypass think_lmi cec processor_thermal_rapl btbcm rapl intel_rapl_common drm_client_lib btmtk drm_kms_helper mtd intel_pmc_core snd_timer ahci intel_cstate intel_lpss_pci processor_thermal_wt_req cfg80211 firmware_attributes_class wmi_bmof bluetooth pmt_telemetry video libahci processor_thermal_power_floor mei_me snd spi_intel_pci i2c_i801 pmt_discovery processor_thermal_mbox intel_lpss intel_uncore libata pl2303 pmt_class i2c_smbus pcspkr idma64 spi_intel rfkill soundcore mei int340x_thermal_zone wmi intel_pmc_ssram_telemetry int3400_thermal acpi_thermal_rel intel_vsec pinctrl_tigerlake acpi_pad acpi_tad drm fuse nfnetlink
[ 40.452569][ T1286] CPU: 3 UID: 0 PID: 1286 Comm: dd Tainted: G S W 7.1.0-rc3+ #1 PREEMPT(lazy)
[ 40.453213][ T1286] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[ 40.453849][ T1286] Hardware name: LENOVO 90XW004HPL/336B, BIOS M5LKT1CA 01/06/2025
[ 40.454439][ T1286] RIP: 0010:disk_free_zone_wplug (blk-zoned.c:592 (discriminator 1))
[ 40.455005][ T1286] Code: 5d 41 5e 41 5f e9 f5 fc e2 fe 83 e2 07 38 d0 7f 08 84 c0 0f 85 82 00 00 00 41 c6 04 24 ff e9 15 ff ff ff 0f 0b e9 2c fe ff ff <0f> 0b a8 01 0f 84 f8 fd ff ff 0f 0b e9 f1 fd ff ff e8 bf 7a 61 ff
All code
========
0: 5d pop %rbp
1: 41 5e pop %r14
3: 41 5f pop %r15
5: e9 f5 fc e2 fe jmp 0xfffffffffee2fcff
a: 83 e2 07 and $0x7,%edx
d: 38 d0 cmp %dl,%al
f: 7f 08 jg 0x19
11: 84 c0 test %al,%al
13: 0f 85 82 00 00 00 jne 0x9b
19: 41 c6 04 24 ff movb $0xff,(%r12)
1e: e9 15 ff ff ff jmp 0xffffffffffffff38
23: 0f 0b ud2
25: e9 2c fe ff ff jmp 0xfffffffffffffe56
2a:* 0f 0b ud2 <-- trapping instruction
2c: a8 01 test $0x1,%al
2e: 0f 84 f8 fd ff ff je 0xfffffffffffffe2c
34: 0f 0b ud2
36: e9 f1 fd ff ff jmp 0xfffffffffffffe2c
3b: e8 bf 7a 61 ff call 0xffffffffff617aff
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: a8 01 test $0x1,%al
4: 0f 84 f8 fd ff ff je 0xfffffffffffffe02
a: 0f 0b ud2
c: e9 f1 fd ff ff jmp 0xfffffffffffffe02
11: e8 bf 7a 61 ff call 0xffffffffff617ad5
[ 40.455652][ T1286] RSP: 0018:ffffc9000179f4d8 EFLAGS: 00010246
[ 40.456258][ T1286] RAX: 0000000000000000 RBX: ffff888883a71800 RCX: ffffffff8293c99a
[ 40.456863][ T1286] RDX: 1ffff1111074e30e RSI: 0000000000000004 RDI: ffff888883a71870
[ 40.457503][ T1286] RBP: ffff8881efd97000 R08: 0000000000000001 R09: ffffed111074e30d
[ 40.458107][ T1286] R10: ffff888883a7186f R11: ffff888200fac01c R12: ffff888890e92940
[ 40.458785][ T1286] R13: ffff88889dac03f8 R14: 000000096a349520 R15: ffff8888a6d6b780
[ 40.459408][ T1286] FS: 00007f265573c780(0000) GS:ffff8887cd24b000(0000) knlGS:0000000000000000
[ 40.460016][ T1286] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 40.460681][ T1286] CR2: 000055b746683f88 CR3: 000000019ef16006 CR4: 0000000000f72ef0
[ 40.461295][ T1286] PKRU: 55555554
[ 40.461905][ T1286] Call Trace:
[ 40.462554][ T1286] <TASK>
[ 40.463161][ T1286] blk_mq_finish_request (blk.h:548 blk-mq.c:786)
[ 40.463864][ T1286] __blk_mq_end_request (blk-mq.c:1164)
[ 40.464518][ T1286] null_queue_rq (block/null_blk/main.c:1703 (discriminator 1)) null_blk
[ 40.465132][ T1286] null_queue_rqs (block/null_blk/main.c:1717) null_blk
[ 40.465828][ T1286] ? __pfx_null_queue_rqs (block/null_blk/main.c:1326) null_blk
[ 40.466460][ T1286] ? _raw_spin_lock_irqsave (linux/instrumented.h:55 linux/atomic/atomic-instrumented.h:1301 asm-generic/qspinlock.h:111 linux/spinlock.h:187 linux/spinlock_api_smp.h:133 locking/spinlock.c:166)
[ 40.467069][ T1286] ? __pfx__raw_spin_lock_irqsave (locking/spinlock.c:273)
[ 40.467748][ T1286] blk_mq_dispatch_queue_requests (blk-mq.c:2903 (discriminator 1))
[ 40.468362][ T1286] blk_mq_flush_plug_list (blk-mq.c:2991)
[ 40.469031][ T1286] ? blk_account_io_start (blk-mq.c:1145 blk-mq.c:1121)
[ 40.469695][ T1286] ? __pfx_blk_mq_flush_plug_list (blk-mq.h:364 (discriminator 1))
[ 40.470310][ T1286] ? blk_mq_submit_bio (blk-mq.c:3231)
[ 40.470968][ T1286] __blk_flush_plug (blk-core.c:1229)
[ 40.471617][ T1286] ? __pfx___blk_flush_plug (linux/list.h:46 (discriminator 2))
[ 40.472224][ T1286] ? gup_fast_fallback (gup.c:3202)
[ 40.472917][ T1286] __submit_bio (blk-core.c:1256 blk-core.c:648)
[ 40.473551][ T1286] ? get_page_from_freelist (page_alloc.c:1866 page_alloc.c:3946)
[ 40.474215][ T1286] ? __pfx___submit_bio (blk-core.c:1257 (discriminator 1))
[ 40.474900][ T1286] submit_bio_noacct_nocheck (blk-core.c:721 blk-core.c:752)
[ 40.475528][ T1286] ? __pfx_submit_bio_noacct_nocheck (blk-core.c:712)
[ 40.476196][ T1286] ? submit_bio_noacct (blk-core.c:881)
[ 40.476875][ T1286] bio_await (bio.c:1499)
[ 40.477495][ T1286] ? __pfx_bio_await (bio.c:1471)
[ 40.478094][ T1286] ? bio_iov_iter_get_pages (bio.c:1266)
[ 40.478753][ T1286] submit_bio_wait (bio.c:1517)
[ 40.479354][[ 40.483105][ T1286] blkdev_write_iter (fops.c:722 fops.c:790)
[ 40.483748][ T1286] vfs_write (read_write.c:595 read_write.c:688)
[ 40.484345][ T1286] ? __pfx_vfs_write (linux/percpu-rwsem.h:131 (discriminator 38))
[ 40.484934][ T1286] ? __pfx_css_rstat_updated (cgroup/rstat.c:548)
[ 40.485546][ T1286] ? do_syscall_64+[ 40.570578][ T1287] ------------[ cut here ]------------
[ 40.571274][ T1287] refcount_t: underflow; use-after-free.
[ 40.571922][ T1287] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xa9/0xf0, CPU#12: dd/1287
[ 40.572594][ T1287] Modules linked in: null_blk loop btrfs libblake2b zstd_compress raid6_pq xor binfmt_misc snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_hda_codec_alc269 snd_hda_codec_realtek_lib snd_hda_scodec_component snd_hda_codec_generic snd_hda_intel snd_sof_pci_intel_tgl snd_sof_pci_intel_cnl snd_sof_intel_hda_generic soundwire_intel snd_sof_intel_hda_sdw_bpt snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda_mlink snd_sof_intel_hda soundwire_cadence intel_rapl_msr snd_sof_pci snd_sof_xtensa_dsp snd_soc_sdw_utils[ 40.572665][ T1287] processor_thermal_wt_hint drm_buddy snd_soc_core ttm btusb platform_temperature_control iwlwifi btrtl snd_compress processor_thermal_soc_slider drm_display_helper spi_nor btintel processor_thermal_rfim snd_pcm irqbypass think_lmi ce[ 40.595153][ T1287] ? __pfx__raw_spin_lock_irqsave (locking/spinlock.c:273)
[ 40.595903][ T1287] blk_mq_dispatch_queue_requests (blk-mq.c:2903 (discriminator 1))
[ 40.596653][ T1287] blk_mq_flush_plug_list (blk-mq.c:2991)
[ 40.597402][ T1287] ? blk_account_io_start (blk-mq.c:1145 blk-mq.c:1121)
[ [ 40.617272][ T1287] ? folio_add_lru_vma (swap.c:536)
[ 40.617965][ T1287] ksys_write (read_write.c:740)
[ 40.618658][ T1287] ? __pfx_ksys_write (read_write.c:724)
[ 40.619354][ T1287] ? folio_add_new_anon_rmap (linux/instrumented.h:82 asm-generic/bitops/instrumented-non-atomic.h:141 linux/page-flags.h:843 linux/page-flags.h:864 linux/mm.h:1724 rmap.c:1697)
[ 40.620041][ T1287] do_syscall_[ 43.443332][ T420] LKP: stdout: 365: /lkp/lkp/src/bin/run-lkp /lkp/jobs/scheduled/igk-rpl-d05/blktests-zbd-004-debian-13-x86_64-20250902.cgz-d9343256aa17-20260530-48630-1qqgxqy-5.yaml
[ 43.443340][ T420]
[ 43.445914][ T420] RESULT_ROOT=/result/blktests/zbd-004/igk-rpl-d05/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-func/gcc-14/d9343256aa173471dbb7f3e02a2177801f2f2136/5
[ 43.445920][ T420]
[ 43.448290][ T420] job=/lkp/jobs/scheduled/igk-rpl-d05/blktests-zbd-004-debian-13-x86_64-20250902.cgz-d9343256aa17-20260530-48630-1qqgxqy-5.yaml
[ 43.448293][ T420]
[ 49.435619][ T420] result_service: raw_upload, RESULT_MNT: /internal-lkp-server/result, RESULT_ROOT: /internal-lkp-server/result/blktests/zbd-004/igk-rpl-d05/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-func/gcc-14/d9343256aa173471dbb7f3e02a2177801f2f2136/5, TMP_RESULT_ROOT: /tmp/lkp/result
[ 49.435628][ T420]
[ 49.438631][ T420] run-job /lkp/jobs/scheduled/igk-rpl-d05/blktests-zbd-004-debian-13-x86_64-20250902.cgz-d9343256aa17-20260530-48630-1qqgxqy-5.yaml
[ 49.438634][ T420]
[ 50.297903][ T420] /usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 http://internal-lkp-server:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/igk-rpl-d05/blktests-zbd-004-debian-13-x86_64-20250902.cgz-d9343256aa17-20260530-48630-1qqgxqy-5.yaml&job_state=running -O /dev/null
[ 50.297912][ T420]
[ 50.300165][ T420] target ucode: 0x4129
[ 50.300168][ T420]
[ 50.301778][ T420] LKP: stdout: 1009: current_version: 4129, target_version: 4129
[ 50.301791][ T420]
[ 50.302957][ T420] check_nr_cpu
[ 50.302959][ T420]
[ 50.304375][ T420] CPU(s): 16
[ 50.304378][ T420]
[ 50.305812][ T420] On-line CPU(s) list: 0-15
[ 50.305815][ T420]
[ 50.307490][ T420] Model name: 13th Gen Intel(R) Core(TM) i7-13620H
[ 50.307494][ T420]
[ 50.308972][ T420] Thread(s) per core: 2
[ 50.308974][ T420]
[ 50.310450][ T420] Core(s) per socket: 10
[ 50.310453][ T420]
[ 50.311846][ T420] Socket(s): 1
[ 50.311849][ T420]
[ 50.313233][ T420] CPU(s) scaling MHz: 30%
[ 50.313236][ T420]
[ 50.314648][ T420] NUMA node(s): 1
[ 50.314650][ T420]
[ 50.316064][ T420] NUMA node0 CPU(s): 0-15
[ 50.316066][ T420]
[ 50.317507][ T420] 2026-05-30 10:54:26 cd /lkp/benchmarks/blktests
[ 50.317509][ T420]
[ 50.319031][ T420] Defaulting to policy_version 2 because kernel supports it.
[ 50.319034][ T420]
[ 50.320596][ T420] Customizing passphrase hashing difficulty for this system...
[ 50.320600][ T420]
[ 50.322106][ T420] Created global config file at "/etc/fscrypt.conf".
[ 50.322108][ T420]
[ 50.323861][ T420] Allow users other than root to create fscrypt metadata on the root filesystem?
[ 50.323864][ T420]
[ 50.326241][ T420] (See https://github.com/google/fscrypt#setting-up-fscrypt-on-a-filesystem) [y/N] Metadata directories created at "/.fscrypt", writable by root only.
[ 50.326244][ T420]
[ 50.327687][ T420] 2026-05-30 10:54:31 echo zbd/004
[ 50.327689][ T420]
[ 50.329072][ T420] 2026-05-30 10:54:31 ./check zbd/004
[ 50.329074][ T420]
[ 50.330721][ T420] zbd/004 => nullb1 (write split across sequential zones)
[ 50.330724][ T420]
[ 50.332420][ T420] zbd/004 => nullb1 (write split across sequential zones) [failed]
[ 50.332423][ T420]
[ 50.333796][ T420] runtime ... 0.246s
[ 50.333798][ T420]
[ 50.335223][ T420] something found in dmesg:
[ 50.335226][ T420]
[ 50.336967][ T420]
[ 40.402539] [ T1255] run blktests zbd/004 at 2026-05-30 10:54:31
[ 50.336970][ T420]
[ 50.338633][ T420]
[ 40.445801] [ T1286] ------------[ cut here ]------------
[ 50.338636][ T420]
[ 50.340724][ T420]
[ 40.446398] [ T1286] WARNING: block/blk-zoned.c:590 at disk_free_zone_wplug+0x26b/0x330, CPU#3: dd/1286
[ 50.340727][ T420]
[ 60.489873][ T1461] EXT4-fs (nvme0n1p3): unmounting filesystem 1516f48d-9247-4757-9a6e-5cfcf67431a2.
[ 62.359503][ T1] watchdog: watchdog0: watchdog did not stop!
[ 62.393655][ T1] watchdog: watchdog0: watchdog did not stop!
[ 62.479655][ T1] r8169 0000:02:00.0 eth0: Link is Down
[ 0.000000][ T0] Linux version 7.1.0-rc3+ (kbuild@6767f1d4f5ea) (gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Sat May 30 06:29:39 CEST 2026
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260531/202605311048.34c03950-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] block: stack zoned resource limits
From: kernel test robot @ 2026-05-31 9:45 UTC (permalink / raw)
To: Yao Sang; +Cc: oe-lkp, lkp, linux-block, Jens Axboe, Yao Sang, oliver.sang
In-Reply-To: <20260520091237.392802-1-sangyao@kylinos.cn>
Hello,
kernel test robot noticed "blktests.zbd/011.fail" on:
commit: c17db973b5faf59694eda2e4ea164b29b69c8973 ("[PATCH] block: stack zoned resource limits")
url: https://github.com/intel-lab-lkp/linux/commits/Yao-Sang/block-stack-zoned-resource-limits/20260520-174028
base: https://git.kernel.org/cgit/linux/kernel/git/axboe/linux.git for-next
patch link: https://lore.kernel.org/all/20260520091237.392802-1-sangyao@kylinos.cn/
patch subject: [PATCH] block: stack zoned resource limits
in testcase: blktests
version: blktests-x86_64-9131687-1_20260529
with following parameters:
test: zbd-011
config: x86_64-rhel-9.4-func
compiler: gcc-14
test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202605311745.77820afc-lkp@intel.com
2026-05-29 09:25:41 cd /lkp/benchmarks/blktests
Defaulting to policy_version 2 because kernel supports it.
Customizing passphrase hashing difficulty for this system...
Created global config file at "/etc/fscrypt.conf".
Allow users other than root to create fscrypt metadata on the root filesystem?
(See https://github.com/google/fscrypt#setting-up-fscrypt-on-a-filesystem) [y/N] Metadata directories created at "/.fscrypt", writable by root only.
2026-05-29 09:25:47 echo zbd/011
2026-05-29 09:25:47 ./check zbd/011
zbd/011 (DM zone resource limits stacking)
zbd/011 (DM zone resource limits stacking) [failed]
runtime ... 6.852s
--- tests/zbd/011.out 2026-05-29 06:56:18.000000000 +0000
+++ /lkp/benchmarks/blktests/results/nodev/zbd/011.out.bad 2026-05-29 09:25:54.319411071 +0000
@@ -1,2 +1,13 @@
Running zbd/011
+Invalid max active zones limit: 64 should be 0
+Test 9 failed: Map 32 CNV zones of the 1st nullb and all SWR zones of the 2nd nullb
+Invalid max active zones limit: 64 should be 0
+Test 11 failed: Map 32 SWR zones of the 1st nullb and all SWR zones of the 2nd nullb
+Invalid max open zones limit: 48 should be 64
+Test 12 failed: Map 128 SWR zones of the 1st nullb and 16 SWR zones of the 2nd nullb
...
(Run 'diff -u tests/zbd/011.out /lkp/benchmarks/blktests/results/nodev/zbd/011.out.bad' to see the entire diff)
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260531/202605311745.77820afc-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [GIT PULL] md-7.2-20260531
From: Yu Kuai @ 2026-05-31 11:26 UTC (permalink / raw)
To: Jens Axboe
Cc: Yu Kuai, linux-raid, linux-block, Abd-Alrhman Masalkhi,
Benjamin Marzinski, Chen Cheng, Christoph Hellwig, Li Nan,
Thorsten Blum
Hi Jens,
Please consider pulling the following changes into your for-7.2/block
branch.
This pull request contains:
Bug Fixes:
- Only requeue dm-raid bios when dm is suspending. (Benjamin Marzinski)
- Reset raid10 read_slot when reusing r10bio for discard. (Chen Cheng)
- Fix raid1/raid10 deadlock in read error recovery path. (Abd-Alrhman Masalkhi)
- Fix raid1/raid10 error-path detection with md_cloned_bio(). (Abd-Alrhman Masalkhi)
- Fix raid1/raid10 bio accounting for split md cloned bios. (Abd-Alrhman Masalkhi)
- Fix raid1 nr_pending leak in REQ_ATOMIC bad-block path. (Abd-Alrhman Masalkhi)
Improvements:
- Skip redundant raid_disks updates when the value is unchanged. (Abd-Alrhman Masalkhi)
Cleanups:
- Update MAINTAINERS email addresses. (Yu Kuai, Li Nan)
- Clean up raid1 read error handling. (Christoph Hellwig)
- Move the exceed_read_errors condition out of fix_read_error(). (Christoph Hellwig)
- Use str_plural() in raid0 dump_zones(). (Thorsten Blum)
Thanks,
Kuai
---
The following changes since commit be34ec59ef061a1cc435a3e066ad71ca675c7fcd:
block: unexport bio_{set,check}_pages_dirty (2026-05-15 08:46:45 -0600)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux.git tags/md-7.2-20260531
for you to fetch changes up to 717359a168bb66ac95f6161715d17e491ee86ca7:
md/raid0: use str_plural helper in dump_zones (2026-05-31 19:09:20 +0800)
----------------------------------------------------------------
Abd-Alrhman Masalkhi (5):
md: skip redundant raid_disks update when value is unchanged
md/raid1,raid10: fix deadlock in read error recovery path
md/raid1,raid10: fix error-path detection with md_cloned_bio()
md/raid1,raid10: fix bio accounting for split md cloned bios
raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path
Benjamin Marzinski (1):
dm-raid: only requeue bios when dm is suspending
Chen Cheng (1):
md/raid10: reset read_slot when reusing r10bio for discard
Christoph Hellwig (2):
md/raid1: cleanup handle_read_error
md/raid1: move the exceed_read_errors condition out of fix_read_error
Li Nan (1):
MAINTAINERS: Update Li Nan's E-mail address
Thorsten Blum (1):
md/raid0: use str_plural helper in dump_zones
Yu Kuai (1):
MAINTAINERS: update Yu Kuai's email address
MAINTAINERS | 6 ++---
drivers/md/dm-raid.c | 6 +++++
drivers/md/md.c | 32 ++++++++++++++++----------
drivers/md/md.h | 7 ++++++
drivers/md/raid0.c | 3 ++-
drivers/md/raid1.c | 63 ++++++++++++++++++++++++++++------------------------
drivers/md/raid10.c | 29 +++++++++++++++---------
drivers/md/raid5.c | 7 ++++--
8 files changed, 96 insertions(+), 57 deletions(-)
^ permalink raw reply
* Re: Observing higher CPU utilization during random IO fio testing
From: Yu Kuai @ 2026-05-31 11:45 UTC (permalink / raw)
To: Wen Xiong
Cc: Jens Axboe, linux-block, tom.leiming, jmoyer, Gjoyce, wenxiong,
yukuai
In-Reply-To: <f7021a9b85cf1aac489d1a07b4fdaaf9@linux.ibm.com>
Hi,
在 2026/5/30 1:13, Wen Xiong 写道:
> On 2026-05-25 00:28, Yu Kuai wrote:
>
>> 在 2026/5/22 5:52, Jens Axboe 写道:
>> Yes, perf data will be helpful. And please show your test in details
>> and I'll
>> check if I can reproduce it.
>
> Hi Yu Kuai,
> Have you reproduced the issue yet?
I don't have exact the same result, but yes I think I can reproduce it. And
consider this is raw disk with qd=1 test, unless some blkio qos policy is enabled
and extra ktime_get() can be optimized, It's expected there will be extra cpu
overhead.
>
> Below is some perf data we took while running random read test:
>
> Test:
> FIO random read with qdepth=1 nj=20, we saw higher CPU utilization in
> this testcase.
>
> Perf record:
> start fio run on one session and kickoff the script in another session
> while test is running
>
> Perf report:
> With blk_start_plug/blk_finish_plug before calling __submit_bio() in
> blk-core.c:
> Top.txt
> 2.41% fio [kernel.kallsyms] [k]
> cpupri_set
> 1.16% fio [kernel.kallsyms] [k]
> queued_spin_lock_slowpath
> 0.75% fio [kernel.kallsyms] [k]
> sbitmap_find_bit
> 0.47% fio [kernel.kallsyms] [k]
> set_next_task_rt
> 0.41% fio [kernel.kallsyms] [k]
> pull_rt_task
> 0.34% fio [kernel.kallsyms] [k]
> enqueue_pushable_task
> …
> 0.02% fio [kernel.kallsyms] [k]
> __blk_flush_plug
> 0.01% fio [kernel.kallsyms] [k]
> blk_add_rq_to_plug
> 0.01% fio [kernel.kallsyms] [k]
> blk_mq_flush_plug_list
> 0.00% fio [kernel.kallsyms] [k]
> blk_attempt_plug_merge
>
> Callgraph.txt
>
> 2.41% fio [kernel.kallsyms] [k]
> cpupri_set
> |
> ---cpupri_set
> |
> |--1.15%--__enqueue_rt_entity
> | enqueue_task_rt
> | enqueue_task
> | ttwu_do_activate
>
>
> Perf report
> Without blk_start_plug and blk_finish_plug before calling
> __submit_bio():
> Top.txt
> 0.67% fio [kernel.kallsyms] [k]
> queued_spin_lock_slowpath
> 0.64% fio [kernel.kallsyms] [k]
> sched_balance_newidle
> 0.47% fio [kernel.kallsyms] [k]
> _raw_spin_lock
> 0.39% fio [kernel.kallsyms] [k]
> sbitmap_find_bit
> 0.35% fio [kernel.kallsyms] [k]
> cpupri_set
> 0.28% fio [kernel.kallsyms] [k]
> work_grab_pending
> 0.24% fio [kernel.kallsyms] [k]
> lookup_ioctx
> 0.23% fio [kernel.kallsyms] [k]
> __schedule
> …
> …
> 0.00% fio [kernel.kallsyms] [k]
> blk_attempt_plug_merge
>
> Call graph.txt:
>
> 0.35% fio [kernel.kallsyms] [k] cpupri_set
> |
> ---cpupri_set
> |
> |--0.17%--arch_local_irq_restore.part.0
> | |
> | |--0.14%--finish_task_switch.isra.0
> | | __schedule
> | | |
> | | |--0.13%--schedule
> | | | |
> | | | |--0.07%--read_events
> …..
> |--0.13%--__enqueue_rt_entity
> | enqueue_task_rt
> | enqueue_task
> | ttwu_do_activate
>
> From above perf data, looks like
> 1. High time spent in cpupri_set(): tasks being enqueued/dequeued
> frequently, more IO scheduling.
> 2. Call more plug routines.
>
> If you need full perf data report, I can email/attach your full report.
I think this is a corner case for qd=1 raw disk test, I'm fine to revert the
commit to fix this problem if needed.
>
> Thanks for your help!
> Wendy
--
Thansk,
Kuai
^ permalink raw reply
* Re: Observing higher CPU utilization during random IO fio testing
From: Yu Kuai @ 2026-05-31 11:56 UTC (permalink / raw)
To: Ming Lei, Wen Xiong; +Cc: linux-block, axboe, jmoyer, Gjoyce, wenxiong, yukuai
In-Reply-To: <aho5HxLsWMEpbUg2@fedora>
Hi,
在 2026/5/30 9:10, Ming Lei 写道:
> On Thu, May 21, 2026 at 02:44:22PM -0500, Wen Xiong wrote:
>> Hi All,
>>
>> Our performance team observed the higher CPU utilization in RHEL10 compared
>> to RHEL9.8, observed the similar issue in upstream kernel(v7.1-rc4) as well
>> when running FIO random IO tests.
>>
>> System configuration:
>> 47 dedicate cores
>> 120 GB memory
>> PCIe4 2-Port 64Gb FC Adapter
>> FlashSystem: FS9500, 12 LUNs/FC port, 100G each LUN.
>>
>> Random IO tests are more CPU intensive than sequential IO tests due to
>> several factors: more context switching, Interrupt Handling, cache
>> Inefficiency etc. We found out the following patch which caused the higher
>> CPU utilization in rhel10 and newer linux kernel:
>>
>> commit 060406c61c7cb4bbd82a02d179decca9c9bb3443 (HEAD)
>> Author: Yu Kuai <yukuai3@huawei.com>
>> Date: Thu May 9 20:38:25 2024 +0800
>>
>> block: add plug while submitting IO
>>
>> So that if caller didn't use plug, for example, __blkdev_direct_IO_simple()
>> and __blkdev_direct_IO_async(), block layer can still benefit from caching
>> nsec time in the plug.
>>
>> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
>> Link:
>> https://lore.kernel.org/r/20240509123825.3225207-1-yukuai1@huaweicloud.com
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>>
>> We reverted above patch in rhel10 kernel and upstream 7.1-rc4, saw lower CPU
>> utilization when doing the same FIO test.
>>
>> The patch adds plugging in __submit_bio() in block layer, maybe cause
>> performance degradation:
>> - Random IO tests have less merging, flush overhead.
>> - More IO scheduler interaction, forces requests through scheduler instead
>> of direct dispatch(direct dispatch to hardware queue)
>> - Poor cache locality during plug operation
> Yes, it is expected to see regression on QD=1 workload.
>
> Adding inner plug for caching timestamp only is not good from plug function viewpoint,
> because only the outer code path(io_uring, libaio, ...) knows exact IO batch size
> and can decide if plug should be used.
>
> Given 060406c61c7c ("block: add plug while submitting IO") doesn't provide
> any performance data, maybe it can be reverted.
>
> I am wondering why not move the timestamp cache into 'task_struct' and get wider users?
Yes, this is exactly what we did in downstream kernels, the time is cached in task_struct
and IO completion also use it. And this is probably why we don't see this regression.
>
>
> Thanks,
> Ming
>
--
Thansk,
Kuai
^ permalink raw reply
* [PATCH] zram: fix partial I/O config check
From: Jianyue Wu @ 2026-05-31 12:35 UTC (permalink / raw)
To: Minchan Kim, Sergey Senozhatsky, Jens Axboe, Chris Li,
Kairui Song, Andrew Morton, Barry Song, Baoquan He
Cc: linux-kernel, linux-block, linux-mm, Christoph Hellwig,
Jianyue Wu
IS_ENABLED() expects a CONFIG_* symbol. Use the real Kconfig symbol so
this warning reflects whether synchronous partial I/O is built in.
Signed-off-by: Jianyue Wu <wujianyue000@gmail.com>
---
zram: fix partial I/O config check
---
drivers/block/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 6e1330ce4bc1..72f89fd5572e 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1510,7 +1510,7 @@ static int read_from_bdev(struct zram *zram, struct page *page, u32 index,
{
atomic64_inc(&zram->stats.bd_reads);
if (!parent) {
- if (WARN_ON_ONCE(!IS_ENABLED(ZRAM_PARTIAL_IO)))
+ if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_ZRAM_PARTIAL_IO)))
return -EIO;
return read_from_bdev_sync(zram, page, index, blk_idx);
}
---
base-commit: 404fb4f38e8f38469dfff4df0205c9d18eeb1f57
change-id: 20260531-zram-fix-partial-io-config-check-on-akpm-c62b972416f8
Best regards,
--
Jianyue Wu <wujianyue000@gmail.com>
^ permalink raw reply related
* Re: [PATCH] zram: fix partial I/O config check
From: Barry Song @ 2026-05-31 21:38 UTC (permalink / raw)
To: Jianyue Wu
Cc: Minchan Kim, Sergey Senozhatsky, Jens Axboe, Chris Li,
Kairui Song, Andrew Morton, Baoquan He, linux-kernel, linux-block,
linux-mm, Christoph Hellwig
In-Reply-To: <20260531-zram-fix-partial-io-config-check-on-akpm-v1-1-eb085d98faea@gmail.com>
On Sun, May 31, 2026 at 8:35 PM Jianyue Wu <wujianyue000@gmail.com> wrote:
>
> IS_ENABLED() expects a CONFIG_* symbol. Use the real Kconfig symbol so
> this warning reflects whether synchronous partial I/O is built in.
>
> Signed-off-by: Jianyue Wu <wujianyue000@gmail.com>
> ---
> zram: fix partial I/O config check
> ---
> drivers/block/zram/zram_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 6e1330ce4bc1..72f89fd5572e 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -1510,7 +1510,7 @@ static int read_from_bdev(struct zram *zram, struct page *page, u32 index,
> {
> atomic64_inc(&zram->stats.bd_reads);
> if (!parent) {
> - if (WARN_ON_ONCE(!IS_ENABLED(ZRAM_PARTIAL_IO)))
> + if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_ZRAM_PARTIAL_IO)))
However, I don't see ZRAM_PARTIAL_IO defined as a Kconfig option.
#if PAGE_SIZE != 4096
static inline bool is_partial_io(struct bio_vec *bvec)
{
return bvec->bv_len != PAGE_SIZE;
}
#define ZRAM_PARTIAL_IO 1
#else
static inline bool is_partial_io(struct bio_vec *bvec)
{
return false;
}
#endif
> return -EIO;
> return read_from_bdev_sync(zram, page, index, blk_idx);
> }
>
> ---
> base-commit: 404fb4f38e8f38469dfff4df0205c9d18eeb1f57
> change-id: 20260531-zram-fix-partial-io-config-check-on-akpm-c62b972416f8
>
> Best regards,
> --
> Jianyue Wu <wujianyue000@gmail.com>
>
^ permalink raw reply
* [PATCH RFC] blk-integrity: fix slab-out-of-bounds in t10_pi_verify on namespace revalidation
From: Samin Y. Chowdhury via B4 Relay @ 2026-05-31 22:45 UTC (permalink / raw)
To: Jens Axboe, Martin K. Petersen, Keith Busch
Cc: linux-block, linux-kernel, Samin Y. Chowdhury, Sungwoo Kim,
Dave Tian, Weidong Zhu, Ruimin Sun
From: "Samin Y. Chowdhury" <samin_c@outlook.com>
Abort early with BLK_STS_PROTECTION if a namespace revalidation changed
bi->metadata_size after bio_integrity_prep() sized the allocation.
Found by FuzzNvme (Syzkaller with FEMU fuzzing framework).
When a namespace is revalidated between bio_integrity_prep() and
bio_integrity_verify_fn(), the integrity profile's metadata_size may
change under the in-flight bio. bio_integrity_verify_fn() re-reads the
live blk_integrity via blk_get_integrity(), so blk_integrity_iterate()
uses the new metadata_size as the per-interval step size against a
buffer sized for the old one, advancing iter->prot_buf past the end of
the allocation.
task 1:
bio_integrity_prep()
bio_integrity_alloc_buf()
len = bio_integrity_bytes(bi, bio_sectors(bio)) ...(1)
bip->bip_iter.bi_size = len
task 2:
nvme_update_ns_info_block()
blk_mq_freeze_queue()
nvme_init_integrity()
bi->metadata_size = head->ms ...(2)
blk_mq_unfreeze_queue()
task 3:
bio_integrity_verify_fn()
bio_integrity_verify()
blk_integrity_iterate()
bi = blk_get_integrity() ...(3)
iter->interval_remaining = 1 << bi->interval_exp
iter->prot_buf += bi->metadata_size per interval
/* step size from (3), buffer sized at (1): overrun */
Fixes: 8098514bd5ca ("block: always allocate integrity buffer when required")
Signed-off-by: Samin Y. Chowdhury <samin_c@outlook.com>
Acked-by: Sungwoo Kim <iam@sung-woo.kim>
Acked-by: Dave Tian <daveti@purdue.edu>
Acked-by: Weidong Zhu <weizhu@fiu.edu>
Acked-by: Ruimin Sun <rsun@fiu.edu>
---
When a namespace is revalidated between bio_integrity_prep() and
bio_integrity_verify_fn(), the integrity profile's metadata_size may
change under the in-flight bio. bio_integrity_verify_fn() re-reads the
live blk_integrity via blk_get_integrity(), so blk_integrity_iterate()
uses the new metadata_size as the per-interval step size against a
buffer sized for the old one, advancing iter->prot_buf past the end of
the allocation.
task 1:
bio_integrity_prep()
bio_integrity_alloc_buf()
len = bio_integrity_bytes(bi, bio_sectors(bio)) ...(1)
bip->bip_iter.bi_size = len
task 2:
nvme_update_ns_info_block()
blk_mq_freeze_queue()
nvme_init_integrity()
bi->metadata_size = head->ms ...(2)
blk_mq_unfreeze_queue()
task 3:
bio_integrity_verify_fn()
bio_integrity_verify()
blk_integrity_iterate()
bi = blk_get_integrity() ...(3)
iter->interval_remaining = 1 << bi->interval_exp
iter->prot_buf += bi->metadata_size per interval
/* step size from (3), buffer sized at (1): overrun */
---
block/bio-integrity-auto.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/block/bio-integrity-auto.c b/block/bio-integrity-auto.c
index 353eed632fc..b404dbaa9f8 100644
--- a/block/bio-integrity-auto.c
+++ b/block/bio-integrity-auto.c
@@ -38,6 +38,18 @@ static void bio_integrity_verify_fn(struct work_struct *work)
struct bio_integrity_data *bid =
container_of(work, struct bio_integrity_data, work);
struct bio *bio = bid->bio;
+ struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk);
+
+ if (bi) {
+ unsigned int required = bio_integrity_bytes(bi, bio_sectors(bio));
+
+ if (unlikely(required > bid->bip.bip_iter.bi_size)) {
+ bio->bi_status = BLK_STS_PROTECTION;
+ bio_integrity_finish(bid);
+ bio_endio(bio);
+ return;
+ }
+ }
bio->bi_status = bio_integrity_verify(bio, &bid->saved_bio_iter);
bio_integrity_finish(bid);
---
base-commit: 174914ea551314c52a61713b9c4bde9e42d48073
change-id: 20260531-blk-integrity-fix-e8109008af54
Best regards,
--
Samin Y. Chowdhury <samin_c@outlook.com>
^ permalink raw reply related
* Re: [PATCH] zram: fix partial I/O config check
From: Jianyue Wu @ 2026-06-01 0:25 UTC (permalink / raw)
To: Barry Song
Cc: Minchan Kim, Sergey Senozhatsky, Jens Axboe, Chris Li,
Kairui Song, Andrew Morton, Baoquan He, linux-kernel, linux-block,
linux-mm, Christoph Hellwig
In-Reply-To: <CAGsJ_4wB5XyUrPpg1O-pkySxo91RsHxaaUkR+Kt+heP4_OeeqA@mail.gmail.com>
On Mon, Jun 1, 2026 at 5:38 AM Barry Song <baohua@kernel.org> wrote:
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index 6e1330ce4bc1..72f89fd5572e 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -1510,7 +1510,7 @@ static int read_from_bdev(struct zram *zram, struct page *page, u32 index,
> > {
> > atomic64_inc(&zram->stats.bd_reads);
> > if (!parent) {
> > - if (WARN_ON_ONCE(!IS_ENABLED(ZRAM_PARTIAL_IO)))
> > + if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_ZRAM_PARTIAL_IO)))
>
> However, I don't see ZRAM_PARTIAL_IO defined as a Kconfig option.
You are right. ZRAM_PARTIAL_IO is a local source-level define, not a
Kconfig symbol.
Please drop this patch.
Sorry for the noise.
Thanks,
Jianyue
^ permalink raw reply
* Re: [PATCH] zram: fix partial I/O config check
From: Baoquan He @ 2026-06-01 0:44 UTC (permalink / raw)
To: Jianyue Wu
Cc: Barry Song, Minchan Kim, Sergey Senozhatsky, Jens Axboe, Chris Li,
Kairui Song, Andrew Morton, linux-kernel, linux-block, linux-mm,
Christoph Hellwig
In-Reply-To: <CAJxJ_jgk8o12OYAi68JznpwKYTUJOUizp2PAZvNz2VdVGJWstw@mail.gmail.com>
On 06/01/26 at 08:25am, Jianyue Wu wrote:
> On Mon, Jun 1, 2026 at 5:38 AM Barry Song <baohua@kernel.org> wrote:
> > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > > index 6e1330ce4bc1..72f89fd5572e 100644
> > > --- a/drivers/block/zram/zram_drv.c
> > > +++ b/drivers/block/zram/zram_drv.c
> > > @@ -1510,7 +1510,7 @@ static int read_from_bdev(struct zram *zram, struct page *page, u32 index,
> > > {
> > > atomic64_inc(&zram->stats.bd_reads);
> > > if (!parent) {
> > > - if (WARN_ON_ONCE(!IS_ENABLED(ZRAM_PARTIAL_IO)))
> > > + if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_ZRAM_PARTIAL_IO)))
> >
> > However, I don't see ZRAM_PARTIAL_IO defined as a Kconfig option.
>
> You are right. ZRAM_PARTIAL_IO is a local source-level define, not a
> Kconfig symbol.
How about removing ZRAM_PARTIAL_IO and use PAGE_SIZE to check?
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 07111455eecf..ca0c29482283 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -221,7 +221,6 @@ static inline bool is_partial_io(struct bio_vec *bvec)
{
return bvec->bv_len != PAGE_SIZE;
}
-#define ZRAM_PARTIAL_IO 1
#else
static inline bool is_partial_io(struct bio_vec *bvec)
{
@@ -1507,7 +1506,7 @@ static int read_from_bdev(struct zram *zram, struct page *page, u32 index,
{
atomic64_inc(&zram->stats.bd_reads);
if (!parent) {
- if (WARN_ON_ONCE(!IS_ENABLED(ZRAM_PARTIAL_IO)))
+ if (WARN_ON_ONCE(PAGE_SIZE == 4096))
return -EIO;
return read_from_bdev_sync(zram, page, index, blk_idx);
}
^ permalink raw reply related
* Re: [PATCH] zram: fix partial I/O config check
From: Jianyue Wu @ 2026-06-01 1:38 UTC (permalink / raw)
To: Baoquan He
Cc: Barry Song, Minchan Kim, Sergey Senozhatsky, Jens Axboe, Chris Li,
Kairui Song, Andrew Morton, linux-kernel, linux-block, linux-mm,
Christoph Hellwig
In-Reply-To: <ahzV6P4n2SICvh4R@MiWiFi-R3L-srv>
On Mon, Jun 1, 2026 at 8:44 AM Baoquan He <baoquan.he@linux.dev> wrote:
>
> On 06/01/26 at 08:25am, Jianyue Wu wrote:
> > On Mon, Jun 1, 2026 at 5:38 AM Barry Song <baohua@kernel.org> wrote:
> > > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > > > index 6e1330ce4bc1..72f89fd5572e 100644
> > > > --- a/drivers/block/zram/zram_drv.c
> > > > +++ b/drivers/block/zram/zram_drv.c
> > > > @@ -1510,7 +1510,7 @@ static int read_from_bdev(struct zram *zram, struct page *page, u32 index,
> > > > {
> > > > atomic64_inc(&zram->stats.bd_reads);
> > > > if (!parent) {
> > > > - if (WARN_ON_ONCE(!IS_ENABLED(ZRAM_PARTIAL_IO)))
> > > > + if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_ZRAM_PARTIAL_IO)))
> > >
> > > However, I don't see ZRAM_PARTIAL_IO defined as a Kconfig option.
> >
> > You are right. ZRAM_PARTIAL_IO is a local source-level define, not a
> > Kconfig symbol.
>
>
> How about removing ZRAM_PARTIAL_IO and use PAGE_SIZE to check?
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 07111455eecf..ca0c29482283 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -221,7 +221,6 @@ static inline bool is_partial_io(struct bio_vec *bvec)
> {
> return bvec->bv_len != PAGE_SIZE;
> }
> -#define ZRAM_PARTIAL_IO 1
> #else
> static inline bool is_partial_io(struct bio_vec *bvec)
> {
> @@ -1507,7 +1506,7 @@ static int read_from_bdev(struct zram *zram, struct page *page, u32 index,
> {
> atomic64_inc(&zram->stats.bd_reads);
> if (!parent) {
> - if (WARN_ON_ONCE(!IS_ENABLED(ZRAM_PARTIAL_IO)))
> + if (WARN_ON_ONCE(PAGE_SIZE == 4096))
> return -EIO;
> return read_from_bdev_sync(zram, page, index, blk_idx);
> }
>
Yes, that looks good. Thanks for the patch.
The synchronous backing-device read is only needed on PAGE_SIZE != 4096
systems, where partial I/O can happen. On 4K systems is_partial_io()
always returns false, so this path should not be hit in normal operation.
Thanks,
Jianyue
^ permalink raw reply
* Re: [PATCH v2 0/2] Add bvec_folio and its kernel-doc
From: Jens Axboe @ 2026-06-01 1:47 UTC (permalink / raw)
To: Matthew Wilcox (Oracle)
Cc: linux-block, linux-kernel, io-uring, linux-mm, Leon Romanovsky,
Christoph Hellwig
In-Reply-To: <20260528175905.1102280-1-willy@infradead.org>
On Thu, 28 May 2026 18:59:02 +0100, Matthew Wilcox (Oracle) wrote:
> Add the convenience helper bvec_folio() to avoid references to bv_page.
> Convert a few of the obvious users.
>
> v2:
> - Tweak the kernel-doc (Christoph)
> - Add the bvec kerneldoc to the documentation build
>
> [...]
Applied, thanks!
[1/2] block: Add bvec_folio()
(no commit info)
[2/2] block: Include bvec.h kernel-doc in the htmldocs
(no commit info)
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH rust-fixes v3 1/1] rust: block: fix GenDisk cleanup paths
From: Jens Axboe @ 2026-06-01 1:47 UTC (permalink / raw)
To: linux-block, rust-for-linux, Ren Wei
Cc: ojeda, boqun, gary, bjorn3_gh, lossin, a.hindborg, aliceryhl,
tmgross, dakr, daniel.almeida, tamird, sunke, yuantan098, bird,
royenheart
In-Reply-To: <b70aff9a920cc42110fe5cf454c3099561863519.1780063368.git.royenheart@gmail.com>
On Sat, 30 May 2026 14:11:54 +0800, Ren Wei wrote:
> GenDiskBuilder::build() still has fallible work after
> __blk_mq_alloc_disk(), but its error path only recovers the
> foreign queue data. That leaks the temporary gendisk and
> request_queue until later teardown. If the caller moved the last
> Arc<TagSet<T>> into build(), the leaked queue can retain blk-mq
> state after the tag set is dropped.
>
> [...]
Applied, thanks!
[1/1] rust: block: fix GenDisk cleanup paths
(no commit info)
Best regards,
--
Jens Axboe
^ permalink raw reply
* [PATCH] blk-iocost: use irq-safe locking in cgroup handlers
From: Yu Kuai @ 2026-06-01 6:13 UTC (permalink / raw)
To: tj, josef; +Cc: axboe, linux-block, linux-kernel
ioc_timer_fn() acquires ioc->lock from timer softirq context. The
io.weight, io.cost.qos and io.cost.model cgroup handlers can take the
same lock from process context, and the direct handler paths must not do
so with interrupts enabled.
A blkcg policy configuration reproducer with lockdep reproduced the
following report:
WARNING: inconsistent lock state
7.1.0-rc2-g1e14adca0199 #1 Not tainted
--------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/2/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
ffff88810f95d0f8 (&ioc->lock){+.?.}-{3:3}, at: ioc_timer_fn+0x3ff/0x3af0
{SOFTIRQ-ON-W} state was registered at:
lock_acquire+0xd4/0x290
_raw_spin_lock+0x3a/0x70
ioc_weight_write+0x35a/0x420
cgroup_file_write+0x1c5/0x4b0
kernfs_fop_write_iter+0x1d7/0x280
vfs_write+0x580/0x630
ksys_write+0xec/0x190
do_syscall_64+0x156/0x490
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Possible unsafe locking scenario:
CPU0
----
lock(&ioc->lock);
<Interrupt>
lock(&ioc->lock);
*** DEADLOCK ***
1 lock held by swapper/2/0:
#0: ffffc90000230d20 ((&ioc->timer)){+.-.}-{0:0}, at:
call_timer_fn+0xba/0x3a0
stack backtrace:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 7.1.0-rc2-g1e14adca0199 #1 PREEMPT ea13f83d4b74a12510d20db4a7d9a0fe8275f05c
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0x54/0x70
print_usage_bug+0x26d/0x280
mark_lock_irq+0x3ef/0x400
mark_lock+0x117/0x190
__lock_acquire+0x592/0x2850
lock_acquire+0xd4/0x290
_raw_spin_lock_irq+0x49/0x80
ioc_timer_fn+0x3ff/0x3af0
call_timer_fn+0x120/0x3a0
__run_timer_base+0x3ad/0x490
run_timer_softirq+0x31/0x60
handle_softirqs+0x1a0/0x550
__irq_exit_rcu+0x8c/0x150
irq_exit_rcu+0xe/0x20
sysvec_apic_timer_interrupt+0x6e/0x80
</IRQ>
Use spin_lock_irq() in the affected process-context handlers. The default
io.weight update already holds blkcg->lock with spin_lock_irq(), so the
nested ioc->lock acquisition there is already IRQ-safe and is left as a
plain spin_lock().
Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost")
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
block/blk-iocost.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/block/blk-iocost.c b/block/blk-iocost.c
index 0cca88a366dc..493cba5523a8 100644
--- a/block/blk-iocost.c
+++ b/block/blk-iocost.c
@@ -3155,11 +3155,11 @@ static ssize_t ioc_weight_write(struct kernfs_open_file *of, char *buf,
goto einval;
}
- spin_lock(&iocg->ioc->lock);
+ spin_lock_irq(&iocg->ioc->lock);
iocg->cfg_weight = v * WEIGHT_ONE;
ioc_now(iocg->ioc, &now);
weight_updated(iocg, &now);
- spin_unlock(&iocg->ioc->lock);
+ spin_unlock_irq(&iocg->ioc->lock);
blkg_conf_exit(&ctx);
return nbytes;
@@ -3180,7 +3180,7 @@ static u64 ioc_qos_prfill(struct seq_file *sf, struct blkg_policy_data *pd,
if (!dname)
return 0;
- spin_lock(&ioc->lock);
+ spin_lock_irq(&ioc->lock);
seq_printf(sf, "%s enable=%d ctrl=%s rpct=%u.%02u rlat=%u wpct=%u.%02u wlat=%u min=%u.%02u max=%u.%02u\n",
dname, ioc->enabled, ioc->user_qos_params ? "user" : "auto",
ioc->params.qos[QOS_RPPM] / 10000,
@@ -3193,7 +3193,7 @@ static u64 ioc_qos_prfill(struct seq_file *sf, struct blkg_policy_data *pd,
ioc->params.qos[QOS_MIN] % 10000 / 100,
ioc->params.qos[QOS_MAX] / 10000,
ioc->params.qos[QOS_MAX] % 10000 / 100);
- spin_unlock(&ioc->lock);
+ spin_unlock_irq(&ioc->lock);
return 0;
}
@@ -3378,14 +3378,14 @@ static u64 ioc_cost_model_prfill(struct seq_file *sf,
if (!dname)
return 0;
- spin_lock(&ioc->lock);
+ spin_lock_irq(&ioc->lock);
seq_printf(sf, "%s ctrl=%s model=linear "
"rbps=%llu rseqiops=%llu rrandiops=%llu "
"wbps=%llu wseqiops=%llu wrandiops=%llu\n",
dname, ioc->user_cost_model ? "user" : "auto",
u[I_LCOEF_RBPS], u[I_LCOEF_RSEQIOPS], u[I_LCOEF_RRANDIOPS],
u[I_LCOEF_WBPS], u[I_LCOEF_WSEQIOPS], u[I_LCOEF_WRANDIOPS]);
- spin_unlock(&ioc->lock);
+ spin_unlock_irq(&ioc->lock);
return 0;
}
--
2.51.0
^ permalink raw reply related
* [PATCH] block, bfq: release cgroup stats with bfq_group
From: Yu Kuai @ 2026-06-01 6:15 UTC (permalink / raw)
To: axboe, linux-block; +Cc: yukuai, linux-kernel, jack
BFQ cgroup stats contain percpu counters embedded in struct bfq_group,
but the old free path destroys them from bfq_pd_free(), which is tied
to blkg policy-data teardown.
That is not the same lifetime as struct bfq_group. BFQ pins bfq_group
while bfq_queue entities refer to it, so bfq_pd_free() can drop the
policy-data reference while other bfq_group references still exist. The
following blkcg change also defers policy-data release through RCU and
leaves BFQ to run the final bfqg_put() from an RCU callback. For that
conversion, stats teardown must belong to the last bfq_group put, not to
policy-data teardown.
Move stats teardown to bfqg_put() so the embedded counters are destroyed
exactly when the last bfq_group reference is released, before kfree(bfqg).
Without this preparatory change, the RCU-delayed policy-data free
conversion reproduced the following KASAN report:
BUG: KASAN: slab-use-after-free in percpu_counter_destroy_many+0xf1/0x2e0
Write of size 8 at addr ffff88811d9409e0 by task test_blkcg/535
CPU: 0 UID: 0 PID: 535 Comm: test_blkcg Not tainted 7.1.0-rc2-g1e14adca0199 #1 PREEMPT ea13f83d4b74a12510d20db4a7d9a0fe8275f05c
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x54/0x70
print_address_description+0x77/0x200
? percpu_counter_destroy_many+0xf1/0x2e0
print_report+0x64/0x70
kasan_report+0x118/0x150
? percpu_counter_destroy_many+0xf1/0x2e0
percpu_counter_destroy_many+0xf1/0x2e0
__mmdrop+0x1d8/0x350
finish_task_switch+0x3f5/0x570
__schedule+0xe8e/0x18a0
schedule+0xfe/0x1c0
schedule_timeout+0x7f/0x1d0
__wait_for_common+0x26c/0x3f0
wait_for_completion_state+0x21/0x40
call_usermodehelper_exec+0x271/0x2c0
__request_module+0x296/0x410
elv_iosched_store+0x1bc/0x2c0
queue_attr_store+0x152/0x1c0
kernfs_fop_write_iter+0x1d7/0x280
vfs_write+0x580/0x630
ksys_write+0xec/0x190
do_syscall_64+0x156/0x490
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Allocated by task 535:
kasan_save_track+0x3e/0x80
__kasan_kmalloc+0x72/0x90
bfq_pd_alloc+0x60/0x100 [bfq]
blkg_create+0x3bb/0xbe0
blkg_lookup_create+0x3a2/0x460
blkg_conf_start+0x24a/0x2d0
bfq_io_set_weight+0x17f/0x430 [bfq]
cgroup_file_write+0x1c5/0x4b0
kernfs_fop_write_iter+0x1d7/0x280
vfs_write+0x580/0x630
ksys_write+0xec/0x190
do_syscall_64+0x156/0x490
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 0:
kasan_save_track+0x3e/0x80
kasan_save_free_info+0x46/0x50
__kasan_slab_free+0x3a/0x60
kfree+0x14e/0x4f0
rcu_core+0x6f3/0xcd0
handle_softirqs+0x1a0/0x550
__irq_exit_rcu+0x8c/0x150
irq_exit_rcu+0xe/0x20
sysvec_apic_timer_interrupt+0x6e/0x80
asm_sysvec_apic_timer_interrupt+0x1a/0x20
Last potentially related work creation:
kasan_save_stack+0x3e/0x60
kasan_record_aux_stack+0x99/0xb0
call_rcu+0x55/0x5c0
blkg_free_workfn+0x130/0x220
process_scheduled_works+0x655/0xb60
worker_thread+0x446/0x600
kthread+0x1f4/0x230
ret_from_fork+0x259/0x420
ret_from_fork_asm+0x1a/0x30
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
block/bfq-cgroup.c | 43 ++++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index ac83b0668764..37ab70930c8d 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -300,6 +300,25 @@ static struct bfq_group *bfqg_parent(struct bfq_group *bfqg)
return pblkg ? blkg_to_bfqg(pblkg) : NULL;
}
+static void bfqg_stats_exit(struct bfqg_stats *stats)
+{
+ blkg_rwstat_exit(&stats->bytes);
+ blkg_rwstat_exit(&stats->ios);
+#ifdef CONFIG_BFQ_CGROUP_DEBUG
+ blkg_rwstat_exit(&stats->merged);
+ blkg_rwstat_exit(&stats->service_time);
+ blkg_rwstat_exit(&stats->wait_time);
+ blkg_rwstat_exit(&stats->queued);
+ bfq_stat_exit(&stats->time);
+ bfq_stat_exit(&stats->avg_queue_size_sum);
+ bfq_stat_exit(&stats->avg_queue_size_samples);
+ bfq_stat_exit(&stats->dequeue);
+ bfq_stat_exit(&stats->group_wait_time);
+ bfq_stat_exit(&stats->idle_time);
+ bfq_stat_exit(&stats->empty_time);
+#endif
+}
+
struct bfq_group *bfqq_group(struct bfq_queue *bfqq)
{
struct bfq_entity *group_entity = bfqq->entity.parent;
@@ -321,8 +340,10 @@ static void bfqg_get(struct bfq_group *bfqg)
static void bfqg_put(struct bfq_group *bfqg)
{
- if (refcount_dec_and_test(&bfqg->ref))
+ if (refcount_dec_and_test(&bfqg->ref)) {
+ bfqg_stats_exit(&bfqg->stats);
kfree(bfqg);
+ }
}
static void bfqg_and_blkg_get(struct bfq_group *bfqg)
@@ -433,25 +454,6 @@ void bfq_init_entity(struct bfq_entity *entity, struct bfq_group *bfqg)
entity->sched_data = &bfqg->sched_data;
}
-static void bfqg_stats_exit(struct bfqg_stats *stats)
-{
- blkg_rwstat_exit(&stats->bytes);
- blkg_rwstat_exit(&stats->ios);
-#ifdef CONFIG_BFQ_CGROUP_DEBUG
- blkg_rwstat_exit(&stats->merged);
- blkg_rwstat_exit(&stats->service_time);
- blkg_rwstat_exit(&stats->wait_time);
- blkg_rwstat_exit(&stats->queued);
- bfq_stat_exit(&stats->time);
- bfq_stat_exit(&stats->avg_queue_size_sum);
- bfq_stat_exit(&stats->avg_queue_size_samples);
- bfq_stat_exit(&stats->dequeue);
- bfq_stat_exit(&stats->group_wait_time);
- bfq_stat_exit(&stats->idle_time);
- bfq_stat_exit(&stats->empty_time);
-#endif
-}
-
static int bfqg_stats_init(struct bfqg_stats *stats, gfp_t gfp)
{
if (blkg_rwstat_init(&stats->bytes, gfp) ||
@@ -552,7 +554,6 @@ static void bfq_pd_free(struct blkg_policy_data *pd)
{
struct bfq_group *bfqg = pd_to_bfqg(pd);
- bfqg_stats_exit(&bfqg->stats);
bfqg_put(bfqg);
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace disks
From: Hannes Reinecke @ 2026-06-01 7:06 UTC (permalink / raw)
To: Achkinazi, Igor, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me,
axboe@kernel.dk
Cc: linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <DS0PR19MB7696FD43E37F19A597121212FD172@DS0PR19MB7696.namprd19.prod.outlook.com>
On 5/30/26 16:34, Achkinazi, Igor wrote:
> Hannes Reinecke wrote:
>> ... or you could introduce __bio_set_dev():
>>
>> diff --git a/include/linux/bio.h b/include/linux/bio.h
>> index 97d747320b35..5a2709adeea7 100644
>> --- a/include/linux/bio.h
>> +++ b/include/linux/bio.h
>> @@ -518,15 +518,20 @@ static inline void blkcg_punt_bio_submit(struct
>> bio *bio)
>> }
>> #endif /* CONFIG_BLK_CGROUP */
>>
>> -static inline void bio_set_dev(struct bio *bio, struct block_device *bdev)
>> +static inline void __bio_set_dev(struct bio *bio, struct block_device
>> *bdev)
>> {
>> - bio_clear_flag(bio, BIO_REMAPPED);
>> if (bio->bi_bdev != bdev)
>> bio_clear_flag(bio, BIO_BPS_THROTTLED);
>> bio->bi_bdev = bdev;
>> bio_associate_blkg(bio);
>> }
>>
>> +static inline void bio_set_dev(struct bio *bio, struct block_device *bdev)
>> +{
>> + bio_clear_flag(bio, BIO_REMAPPED);
>> + __bio_set_dev(bio, bdev);
>> +}
>> +
>> /*
>> * BIO list management for use by remapping drivers (e.g. DM or MD)
>> and loop.
>> *
>>
>> to avoid all this clear-and-set-flag dance.
>
>
> Thanks Hannes. It is a cleaner approach and avoids the clear-and-set
> dance. However it touches the block layer (bio.h) and would need
> wider review and testing across all bio_set_dev callers.
>
> I'd prefer to keep this patch as a minimal, nvme multipath fix that
> Is easy to backport to stable kernels where this race is hitting us
> today. The __bio_set_dev() approach (or Keith's patch that is
> removing set_capacity(0) entirely) could follow as the proper
> long-term solution.
>
Errm. So you are saying: the real solution is too cumbersome,
let someone else do it?
I'll happily give you my reviewed by for the proper solution, and help
you to move the real solution forward.
But pushing the can down the road ... no.
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] loop: reject binding to procfs and sysfs files
From: Christoph Hellwig @ 2026-06-01 7:10 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Jens Axboe, linux-block, LKML, Bart Van Assche, Andrew Morton,
Ming Lei, Damien Le Moal, Christoph Hellwig, Qu Wenruo,
Hillf Danton, linux-fsdevel
In-Reply-To: <148efba2-a0b6-47d7-ac76-b19d2f4b696c@I-love.SAKURA.ne.jp>
On Sat, May 30, 2026 at 10:48:17PM +0900, Tetsuo Handa wrote:
> Writing to pseudo files via /dev/loopX might also cause undesirable
> results.
So don't do it.
> Therefore, explicitly reject binding to pseudo files on procfs
> and sysfs for now. Other filesystems can be appended as needed.
NAK. If people want to do these stupid things we should allow it.
Hardcoding random superblock magics in random drivers is never a good
idea.
^ permalink raw reply
* Re: [PATCH] block: assign caller-specific lockdep class to disk->open_mutex
From: Christoph Hellwig @ 2026-06-01 7:11 UTC (permalink / raw)
To: Bart Van Assche
Cc: Tetsuo Handa, Jens Axboe, linux-block, LKML, Andrew Morton,
Ming Lei, Damien Le Moal, Christoph Hellwig, Qu Wenruo,
Hillf Danton
In-Reply-To: <4cf7ecc7-932c-4589-9d0f-3e025e83e27c@acm.org>
On Sat, May 30, 2026 at 02:15:04PM -0700, Bart Van Assche wrote:
> On 5/30/26 6:45 AM, Tetsuo Handa wrote:
>> - static struct lock_class_key __key; \
>> + static struct lock_class_key __key[2]; \
> The two elements of this array have different roles. From the point of
> view of code readability and maintainability it's probably much better
> to make this a struct with two named members rather than a two-element
> array.
Exactly.
^ permalink raw reply
* Re: [PATCH v2] nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace disks
From: hch @ 2026-06-01 7:13 UTC (permalink / raw)
To: Achkinazi, Igor
Cc: kbusch@kernel.org, hch@lst.de, sagi@grimberg.me, axboe@kernel.dk,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <DS0PR19MB76963295FC34844B413479F9FD092@DS0PR19MB7696.namprd19.prod.outlook.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v5 02/12] block/bdev: Annotate the blk_holder_ops callback functions
From: Christoph Hellwig @ 2026-06-01 7:28 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, linux-block, Christoph Hellwig, Damien Le Moal
In-Reply-To: <b0541615a41fc06f1c0636575db48dd3d7f30e64.1779997063.git.bvanassche@acm.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ 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