* Re: [PATCH v6 00/43] btrfs: add fscrypt support
From: Daniel Vacek @ 2026-04-17 6:17 UTC (permalink / raw)
To: Neal Gompa
Cc: Eric Biggers, 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: <CAEg-Je8ZFJ0MWobrgNpns1-ovh37FeyuvmaR3QSarF_sg87iVg@mail.gmail.com>
On Thu, 16 Apr 2026 at 16:35, Neal Gompa <neal@gompa.dev> wrote:
> On Wed, Apr 15, 2026 at 6:21 AM Daniel Vacek <neelx@suse.com> wrote:
> > On Wed, 15 Apr 2026 at 07:30, Neal Gompa <neal@gompa.dev> wrote:
> > > On Sat, Feb 28, 2026 at 2:57 AM Daniel Vacek <neelx@suse.com> wrote:
> > > > On Fri, 27 Feb 2026 at 23:26, Neal Gompa <ngompa13@gmail.com> wrote:
> > > > > On Fri, Feb 27, 2026 at 10:55 AM Daniel Vacek <neelx@suse.com> wrote:
> > > > > > On Sat, 21 Feb 2026 at 21:56, Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > > On Fri, Feb 06, 2026 at 07:22:32PM +0100, Daniel Vacek wrote:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > These are the remaining parts from former series [1] from Omar, Sweet Tea
> > > > > > > > and Josef. Some bits of it were split into the separate set [2] before.
> > > > > > > >
> > > > > > > > Notably, at this stage encryption is not supported with RAID5/6 setup
> > > > > > > > and send is also isabled for now.
> > > > > > >
> > > > > > > Where does this series apply to? There's no base-commit or git tree,
> > > > > > > and it doesn't apply to mainline or btrfs/for-next.
> > > > > >
> > > > > > Hi Eric,
> > > > > >
> > > > > > My apologies, I did not explicitly mention the base. I'll do it next time.
> > > > > > This was based on for-next @20260127 (commit 80dbfe6512d9c).
> > > > > > Since then, some changes occurred that will require additional
> > > > > > touches. No wonder it does not apply anymore.
> > > > > >
> > > > >
> > > > > When you make your next revision, can you also provide a tag or branch
> > > > > that I can use to grab the patches for testing? It would be easier for
> > > > > me than trying to yoink them down from the emails with how many of
> > > > > them there are...
> > > >
> > > > Sure
> > > >
> > >
> > > Ping to ask about the refreshed patch set. With 7.0 out the door, it'd
> > > be nice to have an updated set with feedback addressed...
> >
> > Hi Neal,
> >
> > I wanted to post a new iteration last week but I hit some new issues
> > that I'm trying to address now.
> > The WIP is here if you want to have a peek:
> >
> > https://github.com/dvacek/linux-btrfs/tree/fscrypt
> >
> > Note, I'll be force-updating it later so don't take even the v7 tag
> > for granted at this point.
> >
>
> Cool. I've got some travel and stuff going on, so I'll probably only
> get to take another crack at this in a couple of weeks. Do you think
> by then you'll have a finalized v7?
Yeah, it's on track. I expect to have it ready in 1-2 weeks (famous last words).
--nX
> --
> 真実はいつも一つ！/ Always, there's only one truth!
^ permalink raw reply
* Re: [PATCH v2 6/6] blk-integrity: avoid sector_t in bip_{get,set}_seed()
From: Christoph Hellwig @ 2026-04-17 7:55 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Christoph Hellwig, Jens Axboe, Sagi Grimberg, Chaitanya Kulkarni,
Martin K. Petersen, Anuj Gupta, linux-block, linux-nvme,
linux-scsi, target-devel, linux-kernel, Christoph Hellwig
In-Reply-To: <CADUfDZpbOhO9BUW_mFZYh9-UZU26_o3rFGBffNTpepk0ogJhZw@mail.gmail.com>
On Thu, Apr 16, 2026 at 06:53:05PM -0700, Caleb Sander Mateos wrote:
> > > +static inline void bip_set_seed(struct bio_integrity_payload *bip,
> > > + const struct blk_integrity *bi,
> > > + const struct bio *bio)
> > > +{
> > > + bip->bip_iter.bi_sector =
> > > + bio_integrity_intervals(bi, bio->bi_iter.bi_sector);
> >
> > The bip is pointed to by the bio, so we don't need to pass it separately.
> > Same for struct blk_integrity.
>
> I did consider that, but all callers already have bip and bi in
> variables that they also use elsewhere. Seemed like it might be
> slightly more efficient to just pass the precomputed values instead of
> looking them up again. Not a big deal either way. I'll go ahead and
> implement your suggestion.
In general I much prefer API-simplicity over a little bit more
efficiency unless we can show it makes a difference that matters.
And given that this is an inline function where compiler tend to
avoid duplicate dereferences anyway I doubt we'll see a difference
here.
^ permalink raw reply
* Re: [PATCH v2] t10-pi: reduce ref tag code duplication
From: Christoph Hellwig @ 2026-04-17 7:56 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Christoph Hellwig, Jens Axboe, linux-block, linux-kernel,
Anuj Gupta
In-Reply-To: <CADUfDZpcNG_GPpZYh9tWKEBjKHD53DVCmQGTrXKQvBpP7PCqsg@mail.gmail.com>
On Thu, Apr 16, 2026 at 08:38:07AM -0700, Caleb Sander Mateos wrote:
> On Wed, Apr 15, 2026 at 10:18 PM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Wed, Apr 15, 2026 at 03:08:47PM -0600, Caleb Sander Mateos wrote:
> > > #ifndef _LINUX_T10_PI_H
> > > #define _LINUX_T10_PI_H
> > >
> > > #include <linux/types.h>
> > > #include <linux/blk-mq.h>
> > > +#include <linux/wordpart.h>
> >
> > We must have already gotten this implicitly given that the code
> > already uses lower_48_bits.
>
> lower_48_bits() is defined (and only used) in this header. Yes,
> wordpart.h is already transitively included by the other headers, but
> I think it's good practice for each file to explicitly include the
> headers defining all the items it uses. It reduces the risk that
> refactoring the other header files in the future will result in a
> compilation error here by dropping the transitive include.
In general pulling in a new header when no new user of it shows up is a
bit weird. I don't want to hold the patch up on this, but there are
folks out there actually dropping not needed includes from headers as
it can significantly reduce compile time. Now this is not a heavily
included header so it's unlikely to make a difference anyway.
^ permalink raw reply
* [PATCH] block: fix deadlock between blk_mq_freeze_queue and blk_mq_dispatch_list
From: Michael Wu @ 2026-04-17 8:27 UTC (permalink / raw)
To: axboe; +Cc: linux-block, linux-kernel
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)
--
2.29.0
^ permalink raw reply related
* [PATCH blktests v2] nvme/068: add a test for multipath delayed removal
From: John Garry @ 2026-04-17 9:48 UTC (permalink / raw)
To: shinichiro.kawasaki, linux-block; +Cc: linux-nvme, kch, nilay, John Garry
For NVMe multipath, the delayed removal feature allows the multipath
gendisk to remain present when all available paths are gone. The purpose of
this feature is to ensure that we keep the gendisk for intermittent path
failures.
The delayed removal works on a timer - when all paths are gone, a timer is
kicked off; once the timer expires and no paths have returned, the gendisk
is removed.
When all paths are gone and the gendisk is still present, all reads and
writes to the disk are queued. If a path returns before the timer
expiration, the timer canceled and the queued IO is submitted;
otherwise they fail when the timer expires.
This testcase covers two scenarios in separate parts:
a. test that IOs submitted after all paths are removed (and do not return)
fail
b. test that IOs submitted between all paths removed and a path
returning succeed
During the period of the timer being active, it must be ensured that the
nvme-core module is not removed. Otherwise the driver may not be present
to handle the timeout expiry. The kernel ensures this by taking a
reference to the module. Ideally, we would try to remove the module during
this test to prove that this is not possible (and the kernel behaves as
expected), but that module will probably not be removable anyway due to
many references. To test this feature, check that the refcount of the
nvme-core module is incremented when the delayed timer is active.
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
Differences to v1:
- Address shellcheck issues (Shinichiro)
- Drop Quick=1 (Shinichiro)
- Reference kernel commit (Nilay)
- Tidy setting refcnt (Nilay)
- Add RB tag from Chaitanya (Thanks!)
Note that a fix for a refcnt issue has been merged into nvme-7.1 queue
diff --git a/common/rc b/common/rc
index 5350057..375c8f1 100644
--- a/common/rc
+++ b/common/rc
@@ -117,6 +117,16 @@ _module_not_in_use() {
fi
}
+_module_use_count() {
+ local refcnt
+ if [ -f "/sys/module/$1/refcnt" ]; then
+ refcnt="$(cat /sys/module/"$1"/refcnt)"
+ echo "$refcnt"
+ return
+ fi
+ echo ""
+}
+
_have_module_param() {
_have_driver "$1" || return
diff --git a/tests/nvme/068 b/tests/nvme/068
new file mode 100755
index 0000000..81f3219
--- /dev/null
+++ b/tests/nvme/068
@@ -0,0 +1,118 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-3.0+
+# Copyright (C) 2026 John Garry
+#
+# Test NVMe multipath delayed removal works as expected. This feature was
+# introduced in commit 62188639ec16 ("nvme-multipath: introduce delayed removal
+# of the multipath head node")
+
+. tests/nvme/rc
+. common/xfs
+
+DESCRIPTION="NVMe multipath delayed removal test"
+
+requires() {
+ _nvme_requires
+ _have_loop
+ _have_module_param_value nvme_core multipath Y
+ _require_nvme_trtype_is_fabrics
+}
+
+set_conditions() {
+ _set_nvme_trtype "$@"
+}
+
+_delayed_nvme_reconnect_ctrl() {
+ sleep 5
+ _nvme_connect_subsys
+}
+
+test() {
+ echo "Running ${TEST_NAME}"
+
+ _setup_nvmet
+
+ local nvmedev
+ local ns
+ local bytes_written
+ local refcnt_orig
+ local refcnt
+ _nvmet_target_setup
+
+ _nvme_connect_subsys
+
+ # Part a: Prove that writes fail when no path returns. Any reads or
+ # writes are queued during the delayed removal period. If no
+ # paths return before the timer expires, then those IOs should
+ # fail.
+ # During the delayed removal period, ensure that the module
+ # refcnt is incremented, to prove that we cannot remove the
+ # driver during this period.
+ nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ refcnt_orig=$(_module_use_count nvme_core)
+ echo 10 > "/sys/block/${ns}/delayed_removal_secs"
+ _nvme_disconnect_ctrl "${nvmedev}"
+ sleep 1
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ "${ns}" = "" ]]; then
+ echo "could not find ns after disconnect"
+ fi
+ refcnt=$(_module_use_count nvme_core)
+ if [ "$refcnt" != "" ] && [ "$refcnt" -le "$refcnt_orig" ]; then
+ echo "module refcount did not increase"
+ fi
+ bytes_written=$(run_xfs_io_pwritev2 /dev/"$ns" 4096)
+ if [ "$bytes_written" == 4096 ]; then
+ echo "wrote successfully after disconnect"
+ fi
+ sleep 10
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ "${ns}" != "" ]]; then
+ echo "found ns after delayed removal"
+ fi
+ refcnt=$(_module_use_count nvme_core)
+ if [ "$refcnt" != "" ] && [ "$refcnt" -ne "$refcnt_orig" ]; then
+ echo "module refcount not as original"
+ fi
+
+ # Part b: Ensure writes for an intermittent disconnect are successful.
+ # During an intermittent disconnect, any reads or writes
+ # queued should succeed after a path returns.
+ # Also ensure module refcount behaviour is as expected, as
+ # above.
+ _nvme_connect_subsys
+
+ nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ refcnt_orig=$(_module_use_count nvme_core)
+ echo 10 > "/sys/block/${ns}/delayed_removal_secs"
+ _nvme_disconnect_ctrl "${nvmedev}"
+ sleep 1
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ "${ns}" = "" ]]; then
+ echo "could not find ns after disconnect"
+ fi
+ _delayed_nvme_reconnect_ctrl "${nvmedev}" &
+ bytes_written=$(run_xfs_io_pwritev2 /dev/"$ns" 4096)
+ if [ "$bytes_written" != 4096 ]; then
+ echo "could not write successfully with reconnect"
+ fi
+ sleep 10
+ ns=$(_find_nvme_ns "${def_subsys_uuid}")
+ if [[ "${ns}" = "" ]]; then
+ echo "could not find ns after delayed reconnect"
+ fi
+ refcnt=$(_module_use_count nvme_core)
+ if [ "$refcnt" != "" ] && [ "$refcnt" -ne "$refcnt_orig" ]; then
+ echo "module refcount not as original"
+ fi
+
+ # Final tidy-up
+ echo 0 > "/sys/block/${ns}/delayed_removal_secs"
+ nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
+ _nvme_disconnect_ctrl "${nvmedev}"
+ _nvmet_target_cleanup
+
+ echo "Test complete"
+}
diff --git a/tests/nvme/068.out b/tests/nvme/068.out
new file mode 100644
index 0000000..b913d19
--- /dev/null
+++ b/tests/nvme/068.out
@@ -0,0 +1,3 @@
+Running nvme/068
+pwrite: Input/output error
+Test complete
--
2.43.5
^ permalink raw reply related
* Re: [PATCH blktests v2] nvme/068: add a test for multipath delayed removal
From: Nilay Shroff @ 2026-04-17 12:36 UTC (permalink / raw)
To: John Garry, shinichiro.kawasaki, linux-block; +Cc: linux-nvme, kch
In-Reply-To: <20260417094854.2135472-1-john.g.garry@oracle.com>
On 4/17/26 3:18 PM, John Garry wrote:
> For NVMe multipath, the delayed removal feature allows the multipath
> gendisk to remain present when all available paths are gone. The purpose of
> this feature is to ensure that we keep the gendisk for intermittent path
> failures.
>
> The delayed removal works on a timer - when all paths are gone, a timer is
> kicked off; once the timer expires and no paths have returned, the gendisk
> is removed.
>
> When all paths are gone and the gendisk is still present, all reads and
> writes to the disk are queued. If a path returns before the timer
> expiration, the timer canceled and the queued IO is submitted;
> otherwise they fail when the timer expires.
>
> This testcase covers two scenarios in separate parts:
> a. test that IOs submitted after all paths are removed (and do not return)
> fail
> b. test that IOs submitted between all paths removed and a path
> returning succeed
>
> During the period of the timer being active, it must be ensured that the
> nvme-core module is not removed. Otherwise the driver may not be present
> to handle the timeout expiry. The kernel ensures this by taking a
> reference to the module. Ideally, we would try to remove the module during
> this test to prove that this is not possible (and the kernel behaves as
> expected), but that module will probably not be removable anyway due to
> many references. To test this feature, check that the refcount of the
> nvme-core module is incremented when the delayed timer is active.
>
> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
> Signed-off-by: John Garry <john.g.garry@oracle.com>
Looks good to me:
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
^ permalink raw reply
* Re: [syzbot] [block?] INFO: task hung in queue_limits_commit_update_frozen
From: syzbot @ 2026-04-17 13:36 UTC (permalink / raw)
To: axboe, linux-block, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <68b016f0.a00a0220.1337b0.0004.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 1f5ffc672165 Fix mismerge of the arm64 / timer-core interr..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=162a24ce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=95729ed00549063a
dashboard link: https://syzkaller.appspot.com/bug?extid=f272bbfbf8498ddadea5
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113e41ba580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6b552538b97f/disk-1f5ffc67.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/724a3a1d69d7/vmlinux-1f5ffc67.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ea684969e2c2/bzImage-1f5ffc67.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f272bbfbf8498ddadea5@syzkaller.appspotmail.com
INFO: task syz.0.17:6086 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.17 state:D stack:25416 pid:6086 tgid:6086 ppid:5943 task_flags:0x480140 flags:0x00080002
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5382 [inline]
__schedule+0x17b4/0x5680 kernel/sched/core.c:7183
__schedule_loop kernel/sched/core.c:7262 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7277
blk_mq_freeze_queue_wait+0x101/0x180 block/blk-mq.c:191
blk_mq_freeze_queue include/linux/blk-mq.h:956 [inline]
queue_limits_commit_update_frozen+0x55/0xd0 block/blk-settings.c:590
nbd_set_size+0x454/0x680 drivers/block/nbd.c:374
nbd_genl_size_set drivers/block/nbd.c:2069 [inline]
nbd_genl_reconfigure+0x7f5/0x1ea0 drivers/block/nbd.c:2373
genl_family_rcv_msg_doit+0x22a/0x330 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x61c/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x75c/0x8e0 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:787 [inline]
__sock_sendmsg net/socket.c:802 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2698
___sys_sendmsg+0x2a5/0x360 net/socket.c:2752
__sys_sendmsg net/socket.c:2784 [inline]
__do_sys_sendmsg net/socket.c:2789 [inline]
__se_sys_sendmsg net/socket.c:2787 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2787
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f197e79c819
RSP: 002b:00007ffdd46f8ca8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f197ea15fa0 RCX: 00007f197e79c819
RDX: 0000000000000000 RSI: 0000200000000100 RDI: 0000000000000004
RBP: 00007f197e832c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f197ea15fac R14: 00007f197ea15fa0 R15: 00007f197ea15fa0
</TASK>
INFO: task syz.3.27:6088 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.3.27 state:D stack:27336 pid:6088 tgid:6088 ppid:5948 task_flags:0x400140 flags:0x00080002
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5382 [inline]
__schedule+0x17b4/0x5680 kernel/sched/core.c:7183
__schedule_loop kernel/sched/core.c:7262 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7277
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7334
__mutex_lock_common kernel/locking/mutex.c:712 [inline]
__mutex_lock+0x7f5/0x1550 kernel/locking/mutex.c:806
genl_lock net/netlink/genetlink.c:35 [inline]
genl_op_lock net/netlink/genetlink.c:60 [inline]
genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x75c/0x8e0 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:787 [inline]
__sock_sendmsg net/socket.c:802 [inline]
__sys_sendto+0x672/0x710 net/socket.c:2265
__do_sys_sendto net/socket.c:2272 [inline]
__se_sys_sendto net/socket.c:2268 [inline]
__x64_sys_sendto+0xde/0x100 net/socket.c:2268
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3f2135d04e
RSP: 002b:00007ffeeed0eab8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00005555561e6500 RCX: 00007f3f2135d04e
RDX: 000000000000001c RSI: 00007ffeeed0ec30 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007ffeeed0eb34 R09: 000000000000000c
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
R13: 00007ffeeed0eb88 R14: 00007ffeeed0ec30 R15: 0000000000000000
</TASK>
Showing all locks held in the system:
4 locks held by kworker/u8:1/13:
1 lock held by khungtaskd/30:
#0: ffffffff8e95d020 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#0: ffffffff8e95d020 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#0: ffffffff8e95d020 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x2e/0x180 kernel/locking/lockdep.c:6775
2 locks held by getty/5579:
#0: ffff888035f540a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
#1: ffffc9000322b2e8 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x45c/0x13a0 drivers/tty/n_tty.c:2211
1 lock held by udevd/5842:
#0: ffff8880268fb350 (&disk->open_mutex){+.+.}-{4:4}, at: bdev_open+0xe0/0xd30 block/bdev.c:953
1 lock held by udevd/5879:
#0: ffff8880268ff350 (&disk->open_mutex){+.+.}-{4:4}, at: bdev_open+0xe0/0xd30 block/bdev.c:953
1 lock held by udevd/5880:
#0: ffff8880269d3350 (&disk->open_mutex){+.+.}-{4:4}, at: bdev_open+0xe0/0xd30 block/bdev.c:953
2 locks held by syz-executor/5944:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/5946:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by kworker/u9:4/5954:
#0: ffff888026b15140 ((wq_completion)nbd6-recv){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3263 [inline]
#0: ffff888026b15140 ((wq_completion)nbd6-recv){+.+.}-{0:0}, at: process_scheduled_works+0xa35/0x1860 kernel/workqueue.c:3371
#1: ffffc900047d7c40 ((work_completion)(&args->work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3264 [inline]
#1: ffffc900047d7c40 ((work_completion)(&args->work)){+.+.}-{0:0}, at: process_scheduled_works+0xa70/0x1860 kernel/workqueue.c:3371
2 locks held by syz-executor/5957:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
1 lock held by udevd/5959:
#0: ffff88802684f350 (&disk->open_mutex){+.+.}-{4:4}, at: bdev_open+0xe0/0xd30 block/bdev.c:953
1 lock held by udevd/6082:
#0: ffff888026a97350 (&disk->open_mutex){+.+.}-{4:4}, at: bdev_open+0xe0/0xd30 block/bdev.c:953
1 lock held by udevd/6085:
#0: ffff888026a93350 (&disk->open_mutex){+.+.}-{4:4}, at: bdev_open+0xe0/0xd30 block/bdev.c:953
6 locks held by syz.0.17/6086:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
#2: ffff888026893a60 (&nbd->config_lock){+.+.}-{4:4}, at: nbd_genl_reconfigure+0x4c1/0x1ea0 drivers/block/nbd.c:2364
#3: ffff8880268cc7c8 (&q->limits_lock){+.+.}-{4:4}, at: queue_limits_start_update include/linux/blkdev.h:1097 [inline]
#3: ffff8880268cc7c8 (&q->limits_lock){+.+.}-{4:4}, at: nbd_set_size+0x263/0x680 drivers/block/nbd.c:354
#4: ffff8880268cc190 (&q->q_usage_counter(io)#49){++++}-{0:0}, at: blk_mq_freeze_queue include/linux/blk-mq.h:956 [inline]
#4: ffff8880268cc190 (&q->q_usage_counter(io)#49){++++}-{0:0}, at: queue_limits_commit_update_frozen+0x55/0xd0 block/blk-settings.c:590
#5: ffff8880268cc1c8 (&q->q_usage_counter(queue)#33){+.+.}-{0:0}, at: blk_mq_freeze_queue include/linux/blk-mq.h:956 [inline]
#5: ffff8880268cc1c8 (&q->q_usage_counter(queue)#33){+.+.}-{0:0}, at: queue_limits_commit_update_frozen+0x55/0xd0 block/blk-settings.c:590
2 locks held by syz.3.27/6088:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6097:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6099:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6119:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6120:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6136:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6146:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6148:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6171:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6172:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6188:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6201:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
2 locks held by syz-executor/6203:
#0: ffffffff8fe3ddc8 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40 net/netlink/genetlink.c:1217
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_lock net/netlink/genetlink.c:35 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_op_lock net/netlink/genetlink.c:60 [inline]
#1: ffffffff8fe3dc00 (genl_mutex){+.+.}-{4:4}, at: genl_rcv_msg+0x10b/0x7a0 net/netlink/genetlink.c:1208
=============================================
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 30 Comm: khungtaskd Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
nmi_cpu_backtrace+0x274/0x2d0 lib/nmi_backtrace.c:113
nmi_trigger_cpumask_backtrace+0x17a/0x300 lib/nmi_backtrace.c:62
trigger_all_cpu_backtrace include/linux/nmi.h:161 [inline]
__sys_info lib/sys_info.c:157 [inline]
sys_info+0x135/0x170 lib/sys_info.c:165
check_hung_uninterruptible_tasks kernel/hung_task.c:346 [inline]
watchdog+0xfaa/0x1000 kernel/hung_task.c:515
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
RIP: 0010:pv_native_safe_halt+0xf/0x20 arch/x86/kernel/paravirt.c:63
Code: 5b 74 02 e9 c3 f6 02 00 cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d e3 4d 16 00 fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 90 90 90 90 90
RSP: 0018:ffffffff8e607dc0 EFLAGS: 00000242
RAX: 000000000016be61 RBX: ffffffff819a67ea RCX: 0000000080000001
RDX: 0000000000000001 RSI: ffffffff8dfb65fa RDI: ffffffff8c27f000
RBP: ffffffff8e607eb0 R08: ffff8880b86339db R09: 1ffff110170c673b
R10: dffffc0000000000 R11: ffffed10170c673c R12: 0000000000000000
R13: 1ffffffff1cd25d8 R14: 0000000000000000 R15: 1ffffffff1cd25d8
FS: 0000000000000000(0000) GS:ffff888125245000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055bbb9380660 CR3: 0000000074fb4000 CR4: 00000000003526f0
Call Trace:
<TASK>
arch_safe_halt arch/x86/kernel/process.c:766 [inline]
default_idle+0x9/0x20 arch/x86/kernel/process.c:767
default_idle_call+0x72/0xb0 kernel/sched/idle.c:122
cpuidle_idle_call kernel/sched/idle.c:199 [inline]
do_idle+0x36a/0x5f0 kernel/sched/idle.c:352
cpu_startup_entry+0x43/0x60 kernel/sched/idle.c:451
rest_init+0x2de/0x300 init/main.c:762
start_kernel+0x38a/0x3e0 init/main.c:1220
x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
x86_64_start_kernel+0x143/0x1c0 arch/x86/kernel/head64.c:291
common_startup_64+0x13e/0x147
</TASK>
---
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.
^ permalink raw reply
* Re: [PATCH v3 0/6] block: fix integrity offset/length conversions
From: Caleb Sander Mateos @ 2026-04-17 15:10 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: <yq18qams3re.fsf@ca-mkp.ca.oracle.com>
On Thu, Apr 16, 2026 at 8:26 PM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
>
> Hi Caleb!
>
> > The block layer's integrity code currently sets the seed (initial
> > reference tag) in units of 512-byte sectors but increments it in units
> > of integrity intervals
>
> I don't necessarily agree with the premise that the seed needs to be
> expressed in any particular unit. The seed is a start value, nothing
> more.
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:
> If the Reference Tag Check bit of the PRCHK field is set to ‘1’ and the namespace is
> formatted for Type 1 or Type 2 protection, then the controller compares the Logical Block
> Reference Tag to the computed reference tag. The computed reference tag depends on
> the Protection Type:
> ▪ If the namespace is formatted for Type 1 protection, the value of the computed
> reference tag for the first logical block of the command is the value contained in
> the Initial Logical Block Reference Tag (ILBRT) or Expected Initial Logical Block
> Reference Tag (EILBRT) field in the command, and the computed reference tag is
> incremented for each subsequent logical block. The controller shall complete the
> command with a status of Invalid Protection Information if the ILBRT field or the
> EILBRT field does not match the value of the least significant bits of the SLBA field
> sized to the number of bits in the Logical Block Reference Tag (refer to section
> 5.3.1.4).
> Note: Unlike SCSI Protection Information Type 1 protection which implicitly uses
> the least significant four bytes of the LBA, the controller always uses the ILBRT or
> EILBRT field and requires the host to initialize the ILBRT or EILBRT field to the
> least significant bits of the LBA sized to the number of bits in the Logical Block
> Reference Tag when Type 1 protection is used.
> ▪ If the namespace is formatted for Type 2 protection, the value of the computed
> reference tag for the first logical block of the command is the value contained in
> the Initial Logical Block Reference Tag (ILBRT) or Expected Initial Logical Block
> Reference Tag (EILBRT) field in the command, and the computed reference tag is
> incremented for each subsequent logical block.
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.
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. This seems completely
unworkable for a block storage device.
>
> We happen to set it to the block number in the block layer since we need
> to be able to know what to compare against on completion (for Type 1 +
> the restrictive Linux implementation of Type 2). But that does not imply
> that the seed needs to be specified in any particular unit. Submitters
> set the seed to whichever value makes sense to them (i.e. it could be
> the offset within a file as opposed to the eventual LBA on the backend
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.
> device). And then that seed is incremented by 1 for each integrity
> interval of data in the PI sent to/received from the device. The
> conversion between the submitter's view of what the first ref tag should
> be (i.e. seed) and what is required by the hardware (for instance lower
> 32 bits of device LBA) is the reason we perform remapping. The seed is
> intentionally different in the submitter's protection envelope compared
> to the device's protection envelope.
>
> Using the block layer block number as seed was just a convenience since
> that provided a predictable value for any I/O that had its PI
> autogenerated. I never intended for the actual LBA to be used as seed
> value on a 4Kn device. Initially we just used 0 as the seed. Leveraging
> the block number just added a bit of additional protection.
>
> I confess I haven't tested 4Kn in a while since things sort of converged
> on 512e. But I used to run nightly tests on a SCSI storage with 4Kn
> blocks just fine.
>
> > This looks to be a longstanding bug affecting block devices that
> > support integrity with block sizes > 512 bytes; I'm surprised it
> > wasn't noticed before.
>
> Are you seeing this with NVMe or SCSI?
With a ublk device. It should affect any block device that supports
integrity and has a logical block size > 512.
Best,
Caleb
^ permalink raw reply
* Re: [PATCH] block: fix deadlock between blk_mq_freeze_queue and blk_mq_dispatch_list
From: Ming Lei @ 2026-04-17 15:15 UTC (permalink / raw)
To: Michael Wu; +Cc: axboe, linux-block, linux-kernel
In-Reply-To: <20260417082744.30124-1-michael@allwinnertech.com>
On Fri, Apr 17, 2026 at 04:27:44PM +0800, 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();
> }
It looks one strange scheduler behavior, io_schedule_prepare() is scheduled out, and never scheduled
back. But the above code block can't sleep, so question why it doesn't get
chance to schedule back.
Can this issue be triggered on upstream kernel?
If it is really the reason, the fix may not work, because it can be
preempted before calling percpu_ref_get(), when requests in the plug list
actually grab queue usage counter too.
BTW, preempt_disable() should be enough. If it is really needed, the proper
callsite may be io_schedule_prepare().
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH v2] t10-pi: reduce ref tag code duplication
From: Caleb Sander Mateos @ 2026-04-17 15:34 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jens Axboe, linux-block, linux-kernel, Anuj Gupta
In-Reply-To: <aeHnx2GcBmutcsBW@infradead.org>
On Fri, Apr 17, 2026 at 12:56 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Apr 16, 2026 at 08:38:07AM -0700, Caleb Sander Mateos wrote:
> > On Wed, Apr 15, 2026 at 10:18 PM Christoph Hellwig <hch@infradead.org> wrote:
> > >
> > > On Wed, Apr 15, 2026 at 03:08:47PM -0600, Caleb Sander Mateos wrote:
> > > > #ifndef _LINUX_T10_PI_H
> > > > #define _LINUX_T10_PI_H
> > > >
> > > > #include <linux/types.h>
> > > > #include <linux/blk-mq.h>
> > > > +#include <linux/wordpart.h>
> > >
> > > We must have already gotten this implicitly given that the code
> > > already uses lower_48_bits.
> >
> > lower_48_bits() is defined (and only used) in this header. Yes,
> > wordpart.h is already transitively included by the other headers, but
> > I think it's good practice for each file to explicitly include the
> > headers defining all the items it uses. It reduces the risk that
> > refactoring the other header files in the future will result in a
> > compilation error here by dropping the transitive include.
>
> In general pulling in a new header when no new user of it shows up is a
> bit weird. I don't want to hold the patch up on this, but there are
I'm not sure what you mean by "no new user". There weren't previously
any uses of items from wordpart.h in t10-pi.h, but now it's using
lower_32_bits(). Personally, I think lower_32_bits() seems excessive
when we could just cast to u32, but I was following your suggestion...
> folks out there actually dropping not needed includes from headers as
> it can significantly reduce compile time. Now this is not a heavily
> included header so it's unlikely to make a difference anyway.
Is a file being included by the preprocessor multiple times really
that expensive? I would have assumed it would be cached the first time
it was included.
Best,
Caleb
^ permalink raw reply
* Re: [PATCH v11 11/13] blk-mq: prevent offlining hk CPUs with associated online isolated CPUs
From: Marco Crivellari @ 2026-04-17 16:11 UTC (permalink / raw)
To: atomlin
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,
Marco Crivellari
In-Reply-To: <20260416192942.1243421-12-atomlin@atomlin.com>
Hi,
Seems like the commit log of this patch is duplicated, isn't it?
I noticed it's like this from v7.
Thanks!
--
Marco Crivellari
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] t10-pi: reduce ref tag code duplication
From: Keith Busch @ 2026-04-17 16:52 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Christoph Hellwig, Jens Axboe, linux-block, linux-kernel,
Anuj Gupta
In-Reply-To: <CADUfDZqDz9a4yBOq77mTOjQzNEwra6eh6oZFng-mzjmC5ivD8g@mail.gmail.com>
On Fri, Apr 17, 2026 at 08:34:30AM -0700, Caleb Sander Mateos wrote:
> On Fri, Apr 17, 2026 at 12:56 AM Christoph Hellwig <hch@infradead.org> wrote:
> > folks out there actually dropping not needed includes from headers as
> > it can significantly reduce compile time. Now this is not a heavily
> > included header so it's unlikely to make a difference anyway.
>
> Is a file being included by the preprocessor multiple times really
> that expensive? I would have assumed it would be cached the first time
> it was included.
Do modern compilers even incur a cost? They all have "multiple-include
optimization" features as far as i know. Not that we use "#prama once"
in kernel, but compilers look like they're smart enough to recognize the
#ifdef guards for the same purpose.
https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html#The-Multiple-Include-Optimization
^ permalink raw reply
* Re: [PATCH 1/2] Revert "nvmet-tcp: Don't free SQ on authentication success"
From: Chris Leech @ 2026-04-17 16:57 UTC (permalink / raw)
To: alistair23
Cc: hare, hch, sagi, kch, kbusch, linux-nvme, linux-kernel, yi.zhang,
mlombard, linux-block, shinichiro.kawasaki, Alistair Francis
In-Reply-To: <20260417004809.2894745-1-alistair.francis@wdc.com>
On Fri, Apr 17, 2026 at 10:48:08AM +1000, alistair23@gmail.com wrote:
> From: Alistair Francis <alistair.francis@wdc.com>
>
> In an attempt to fix REPLACETLSPSK we stopped freeing the secrets on
> successful connections. This resulted in memory leaks in the kernel, so
> let's revert the commit. A improved fix is being developed to just avoid
> clearing the tls_key variable.
>
> This reverts commit 2e6eb6b277f593b98f151ea8eff1beb558bbea3b.
>
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> ---
> drivers/nvme/target/fabrics-cmd-auth.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
Closes: https://lore.kernel.org/linux-nvme/CAHj4cs-u3MWQR4idywptMfjEYi4YwObWFx4KVib35dZ5HMBDdw@mail.gmail.com
Reviewed-by: Chris Leech <cleech@redhat.com>
> diff --git a/drivers/nvme/target/fabrics-cmd-auth.c b/drivers/nvme/target/fabrics-cmd-auth.c
> index b9ab80c7a6941..f1e613e7c63e5 100644
> --- a/drivers/nvme/target/fabrics-cmd-auth.c
> +++ b/drivers/nvme/target/fabrics-cmd-auth.c
> @@ -395,10 +395,9 @@ void nvmet_execute_auth_send(struct nvmet_req *req)
> goto complete;
> }
> /* Final states, clear up variables */
> - if (req->sq->dhchap_step == NVME_AUTH_DHCHAP_MESSAGE_FAILURE2) {
> - nvmet_auth_sq_free(req->sq);
> + nvmet_auth_sq_free(req->sq);
> + if (req->sq->dhchap_step == NVME_AUTH_DHCHAP_MESSAGE_FAILURE2)
> nvmet_ctrl_fatal_error(ctrl);
> - }
>
> complete:
> nvmet_req_complete(req, status);
> @@ -574,7 +573,9 @@ void nvmet_execute_auth_receive(struct nvmet_req *req)
> status = nvmet_copy_to_sgl(req, 0, d, al);
> kfree(d);
> done:
> - if (req->sq->dhchap_step == NVME_AUTH_DHCHAP_MESSAGE_FAILURE1) {
> + if (req->sq->dhchap_step == NVME_AUTH_DHCHAP_MESSAGE_SUCCESS2)
> + nvmet_auth_sq_free(req->sq);
> + else if (req->sq->dhchap_step == NVME_AUTH_DHCHAP_MESSAGE_FAILURE1) {
> nvmet_auth_sq_free(req->sq);
> nvmet_ctrl_fatal_error(ctrl);
> }
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH 2/2] nvmet-tcp: Don't clear tls_key when freeing sq
From: Chris Leech @ 2026-04-17 16:58 UTC (permalink / raw)
To: alistair23
Cc: hare, hch, sagi, kch, kbusch, linux-nvme, linux-kernel, yi.zhang,
mlombard, linux-block, shinichiro.kawasaki, Alistair Francis
In-Reply-To: <20260417004809.2894745-2-alistair.francis@wdc.com>
On Fri, Apr 17, 2026 at 10:48:09AM +1000, alistair23@gmail.com wrote:
> From: Alistair Francis <alistair.francis@wdc.com>
>
> Curently after the host sends a REPLACETLSPSK we free the TLS keys as
> part of calling nvmet_auth_sq_free() on success. This means when the
> host sends a follow up REPLACETLSPSK we return CONCAT_MISMATCH as the
> check for !nvmet_queue_tls_keyid(req->sq) fails.
>
> A previous attempt to fix this involed not calling nvmet_auth_sq_free()
> on successful connections, but that results in memory leaks. Instead we
> should not clear `tls_key` in nvmet_auth_sq_free(), as that was
> incorrectly wiping the tls keys which are used for the session.
>
> This patch ensures we correctly free the ephemeral session key on
> connection, yet we don't free the TLS key unless closing the connection.
>
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> ---
> drivers/nvme/target/auth.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Reviewed-by: Chris Leech <cleech@redhat.com>
^ permalink raw reply
* Re: [PATCH v11 11/13] blk-mq: prevent offlining hk CPUs with associated online isolated CPUs
From: Aaron Tomlin @ 2026-04-17 18:06 UTC (permalink / raw)
To: Marco Crivellari
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: <20260417161116.373130-1-marco.crivellari@suse.com>
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
On Fri, Apr 17, 2026 at 06:11:16PM +0200, Marco Crivellari wrote:
> Hi,
>
> Seems like the commit log of this patch is duplicated, isn't it?
> I noticed it's like this from v7.
>
Hi Marco,
Yes, that is correct. Thank you for bringing this to my attention.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/2] blk-mq: introduce tag starvation observability
From: Aaron Tomlin @ 2026-04-17 18:15 UTC (permalink / raw)
To: axboe, rostedt, mhiramat, mathieu.desnoyers
Cc: johannes.thumshirn, kch, bvanassche, dlemoal, ritesh.list,
loberman, neelx, sean, mproche, chjohnst, nick.lange, linux-block,
linux-kernel, linux-trace-kernel
In-Reply-To: <20260319221956.332770-1-atomlin@atomlin.com>
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
On Thu, Mar 19, 2026 at 06:19:54PM -0400, Aaron Tomlin wrote:
> In high-performance storage environments, particularly when utilising RAID
> controllers with shared tag sets (BLK_MQ_F_TAG_HCTX_SHARED), severe latency
> spikes can occur when fast devices are starved of available tags.
> Currently, diagnosing this specific queue contention requires deploying
> dynamic kprobes or inferring sleep states, which lacks a simple,
> out-of-the-box diagnostic path.
>
> This short series introduces dedicated, low-overhead observability for tag
> exhaustion events in the block layer:
>
> - Patch 1 introduces the "block_rq_tag_wait" tracepoint in the tag
> allocation slow-path to capture precise, event-based starvation.
>
> - Patch 2 complements this by exposing "wait_on_hw_tag" and
> "wait_on_sched_tag" atomic counters via debugfs for quick,
> point-in-time cumulative polling.
>
> Together, these provide storage engineers with zero-configuration
> mechanisms to definitively identify shared-tag bottlenecks.
Hi Jens, Steve, Masami,
Just a friendly ping on this patch.
Please let me know if there is any feedback, or if you need me to make any
adjustments.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] blk-mq: expose tag starvation counts via debugfs
From: Bart Van Assche @ 2026-04-17 18:28 UTC (permalink / raw)
To: Aaron Tomlin, axboe, rostedt, mhiramat, mathieu.desnoyers
Cc: johannes.thumshirn, kch, dlemoal, ritesh.list, loberman, neelx,
sean, mproche, chjohnst, linux-block, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260319221956.332770-3-atomlin@atomlin.com>
On 3/19/26 3:19 PM, Aaron Tomlin wrote:
> To guarantee zero performance overhead for production kernels compiled
> without debugfs, the underlying atomic_t variables and their associated
> increment routines are strictly guarded behind CONFIG_BLK_DEBUG_FS.
> When this configuration is disabled, the tracking logic compiles down
> to a safe no-op.
I don't think that's sufficient. Please use per-cpu counters to minimize
the overhead for kernels in which debugfs is enabled.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v3 2/2] blk-mq: expose tag starvation counts via debugfs
From: Jens Axboe @ 2026-04-17 20:16 UTC (permalink / raw)
To: Bart Van Assche, Aaron Tomlin, rostedt, mhiramat,
mathieu.desnoyers
Cc: johannes.thumshirn, kch, dlemoal, ritesh.list, loberman, neelx,
sean, mproche, chjohnst, linux-block, linux-kernel,
linux-trace-kernel
In-Reply-To: <ac8d9fd1-15c6-44cf-ba5a-85bd4aefce9b@acm.org>
On 4/17/26 12:28 PM, Bart Van Assche wrote:
> On 3/19/26 3:19 PM, Aaron Tomlin wrote:
>> To guarantee zero performance overhead for production kernels compiled
>> without debugfs, the underlying atomic_t variables and their associated
>> increment routines are strictly guarded behind CONFIG_BLK_DEBUG_FS.
>> When this configuration is disabled, the tracking logic compiles down
>> to a safe no-op.
>
> I don't think that's sufficient. Please use per-cpu counters to
> minimize the overhead for kernels in which debugfs is enabled.
Agree, this is the usual nonsense of thinking you can hide any overhead
behind a config option, when in practice production kernels very much DO
have CONFIG_DEBUGFS enabled.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] t10-pi: reduce ref tag code duplication
From: Jens Axboe @ 2026-04-17 20:39 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: linux-block, linux-kernel, Christoph Hellwig, Anuj Gupta
In-Reply-To: <20260415210847.1730016-1-csander@purestorage.com>
On Wed, 15 Apr 2026 15:08:47 -0600, Caleb Sander Mateos wrote:
> t10_pi_ref_tag() and ext_pi_ref_tag() are identical except for the final
> truncation of the ref tag to 32 or 48 bits. Factor out a helper
> full_pi_ref_tag() to return the untruncated ref tag and use it in
> t10_pi_ref_tag() and ext_pi_ref_tag().
Applied, thanks!
[1/1] t10-pi: reduce ref tag code duplication
commit: 2f5015461984caa8ebf265a60b22f38c94d9c70a
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH V3] ublk: use unchecked copy helpers for bio page data
From: Jens Axboe @ 2026-04-17 20:39 UTC (permalink / raw)
To: linux-block, Ming Lei; +Cc: Caleb Sander Mateos, Ming Lei
In-Reply-To: <20260415230246.808176-1-tom.leiming@gmail.com>
On Thu, 16 Apr 2026 07:02:46 +0800, Ming Lei wrote:
> Bio pages may originate from slab caches that lack a usercopy region
> (e.g. jbd2 frozen metadata buffers allocated via jbd2_alloc()).
> When CONFIG_HARDENED_USERCOPY is enabled, copy_to_iter() calls
> check_copy_size() which rejects these slab pages, triggering a
> kernel BUG in usercopy_abort().
>
> This is a false positive: the data is ordinary block I/O content —
> the same data the loop driver writes to its backing file via
> vfs_iter_write(). The bvec length is always trusted, so the size
> check in check_copy_size() is not needed either.
>
> [...]
Applied, thanks!
[1/1] ublk: use unchecked copy helpers for bio page data
commit: a7c9fa7f6601c84d27cdd43bd96e8fcbacfb7479
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] floppy: fix reference leak on platform_device_register() failure
From: Jens Axboe @ 2026-04-17 20:39 UTC (permalink / raw)
To: Denis Efremov, Greg Kroah-Hartman, linux-block, linux-kernel,
Guangshuo Li
Cc: stable
In-Reply-To: <20260415145708.3331818-1-lgs201920130244@gmail.com>
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
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2 0/2] block: fix pgmap handling for zone device pages in bio merge paths
From: Jens Axboe @ 2026-04-17 20:39 UTC (permalink / raw)
To: Naman Jain
Cc: Christoph Hellwig, Chaitanya Kulkarni, John Hubbard,
Logan Gunthorpe, linux-kernel, linux-block, Saurabh Sengar,
Long Li, Michael Kelley
In-Reply-To: <20260410153414.4159050-1-namjain@linux.microsoft.com>
On Fri, 10 Apr 2026 15:34:12 +0000, Naman Jain wrote:
> When zone device memory is registered in multiple chunks, each chunk
> gets its own dev_pagemap. A single bio can contain bvecs from different
> pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the
> outer loop in bio_iov_iter_get_pages() continues filling the same bio.
>
> There are two problems with the current code:
>
> [...]
Applied, thanks!
[1/2] block: add pgmap check to biovec_phys_mergeable
commit: 13920e4b7b784b40cf4519ff1f0f3e513476a499
[2/2] block: relax pgmap check in bio_add_page for compatible zone device pages
commit: 41c665aae2b5dbecddddcc8ace344caf630cc7a4
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [RFC PATCH] zram: support asynchronous GC for lazy slot freeing
From: Barry Song @ 2026-04-17 21:59 UTC (permalink / raw)
To: Kairui Song
Cc: minchan, senozhatsky, akpm, linux-mm, axboe, linux-block,
linux-kernel, kasong, chrisl, justinjiang, liulei.rjpt,
Xueyuan Chen, Wenchao Hao
In-Reply-To: <adt3Q_SRToF6fb3W@KASONG-MC4>
On Sun, Apr 12, 2026 at 7:48 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Sun, Apr 12, 2026 at 02:04:50PM +0800, Barry Song (Xiaomi) wrote:
> > Swap freeing can be expensive when unmapping a VMA containing
> > many swap entries. This has been reported to significantly
> > delay memory reclamation during Android’s low-memory killing,
> > especially when multiple processes are terminated to free
> > memory, with slot_free() accounting for more than 80% of
> > the total cost of freeing swap entries.
> >
> > Two earlier attempts by Lei and Zhiguo added a new thread in the mm core
> > to asynchronously collect and free swap entries [1][2], but the
> > design itself is fairly complex.
> >
> > When anon folios and swap entries are mixed within a
> > process, reclaiming anon folios from killed processes
> > helps return memory to the system as quickly as possible,
> > so that newly launched applications can satisfy their
> > memory demands. It is not ideal for swap freeing to block
> > anon folio freeing. On the other hand, swap freeing can
> > still return memory to the system, although at a slower
> > rate due to memory compression.
> >
> > Therefore, in zram, we introduce a GC worker to allow anon
> > folio freeing and slot_free to run in parallel, since
> > slot_free is performed asynchronously, maximizing the rate at
> > which memory is returned to the system.
> >
> > Xueyuan’s test on RK3588 shows that unmapping a 256MB swap-filled
> > VMA becomes 3.4× faster when pinning tasks to CPU2, reducing the
> > execution time from 63,102,982 ns to 18,570,726 ns.
> >
> > A positive side effect is that async GC also slightly improves
> > do_swap_page() performance, as it no longer has to wait for
> > slot_free() to complete.
> >
> > Xueyuan’s test shows that swapping in 256MB of data (each page
> > filled with repeating patterns such as “1024 one”, “1024 two”,
> > “1024 three”, and “1024 four”) reduces execution time from
> > 1,358,133,886 ns to 1,104,315,986 ns, achieving a 1.22× speedup.
> >
> > [1] https://lore.kernel.org/all/20240805153639.1057-1-justinjiang@vivo.com/
> > [2] https://lore.kernel.org/all/20250909065349.574894-1-liulei.rjpt@vivo.com/
> >
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
>
> Hi Barry
>
> This looks an interesting idea to me.
>
> > ---
> > drivers/block/zram/zram_drv.c | 56 ++++++++++++++++++++++++++++++++++-
> > drivers/block/zram/zram_drv.h | 3 ++
> > 2 files changed, 58 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index c2afd1c34f4a..f5c07eb997a8 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -1958,6 +1958,23 @@ static ssize_t debug_stat_show(struct device *dev,
> > return ret;
> > }
> >
> > +static void gc_slots_free(struct zram *zram)
> > +{
> > + size_t num_pages = zram->disksize >> PAGE_SHIFT;
> > + unsigned long index;
> > +
> > + index = find_next_bit(zram->gc_map, num_pages, 0);
> > + while (index < num_pages) {
> > + if (slot_trylock(zram, index)) {
> > + if (test_bit(index, zram->gc_map))
> > + slot_free(zram, index);
> > + slot_unlock(zram, index);
> > + cond_resched();
> > + }
> > + index = find_next_bit(zram->gc_map, num_pages, index + 1);
> > + }
> > +}
> > +
>
> The ideas looks interesting but the implementation looks not that
> optimal to me. find_next_bit does a O(n) looks up for every gc call
> looks really expensive if the pending slot is at tail.
Agreed. It’s essentially a prototype at this stage to demonstrate the
idea.
>
> Perhaps a percpu stack can be used, something like the folio batch?
I guess a major difference is that folio batching aims to reduce
lruvec lock contention. Once a CPU’s slot space is empty, it batches
draining folios into the lruvec by checking whether some slots can
share the same lock. This procedure is synchronous within
folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn);
In our case, we might not want a synchronous procedure, so each CPU
could launch its own workqueue. I’m not sure whether this is actually
beneficial, as it might trigger the zsmalloc lock contention we are
trying to eliminate.
If we end up wanting to drain all CPUs together, that would make things
quite complex again.
So I guess a hierarchical bitmap, an XArray, or even a simple array
could work. If we cap it at 64MB, the array would be at most 128KB on a
PAGE_SIZE=4KB system.
I am CC’ing Wenchao, who may be interested in further measurements
and also involved in a more efficient implementation.
>
> > - slot_free(zram, index);
> > + if (!try_slot_lazy_free(zram, index))
> > + slot_free(zram, index);
>
> What is making this slot_free so costly? zs_free?
>
> > slot_unlock(zram, index);
> > }
> >
> > diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
> > index 08d1774c15db..1f3ffd79fcb1 100644
> > --- a/drivers/block/zram/zram_drv.h
> > +++ b/drivers/block/zram/zram_drv.h
> > @@ -88,6 +88,7 @@ struct zram_stats {
> > atomic64_t pages_stored; /* no. of pages currently stored */
> > atomic_long_t max_used_pages; /* no. of maximum pages stored */
> > atomic64_t miss_free; /* no. of missed free */
> > + atomic64_t gc_slots; /* no. of queued for lazy free by gc */
>
> Maybe we want to track the size of content being delayed instead
> of slots number? I saw there is a 30000 hard limit for that.
Yep, definitely we want size, not number of pages, since PAGE_SIZE
is not constant.
>
> Perhaps it will make more sense if we have a "buffer size"
> (e.g. 64M), seems more intuitive to me. e.g. the ZRAM module can occupy
> at most 64M of memory, so the delayed free won't cause a significant
> global pressure.
>
> Also I think this patch is batching the memory free operations, so the
> workqueue or design can also be further optimized for batching, for
> example if the zs_free is the expensive part then maybe we shall just
> clear the handler for the freeing slot and leave the handler in a
> percpu stack, then batch free these handlers. zsmalloc might make
> use some batch optimization based on that too, something like
> kmem_cache_free_bulk but for zsmalloc?
I’m not really sure a per-CPU approach is the right direction, since
zsmalloc already has a lot of contention we may want to eliminate. If
we introduce per-CPU workqueues or similar mechanisms, we might end up
increasing contention rather than reducing it.
A kmem_cache_free_bulk()-like approach might be a good direction to
investigate for zsmalloc. I guess Xueyuan is also thinking about it?
Right now, zsmalloc frequently takes and releases multiple locks for
each individual.
>
> if zs_free is not all the expensive part, I took a look at slot_free
> maybe a lot of read / write of slot data can be merged.
>
> This patch currently doesn't reduce the total amount of work, but
> if above idea works, a lot of redundant operations might be be dropped,
> result in better performance in every case.
Yep, hopefully we can optimize for every case. Of course, that will
take a lot of time :-)
>
> Just my two cents and ideas, not sure if I got everything correct.
> Looking forward for more disscussion on this :)
Thanks for your suggestions—they are always welcome. We may
discuss this further.
Best Regards
Barry
^ permalink raw reply
* [syzbot] [block?] general protection fault in lo_rw_aio
From: syzbot @ 2026-04-18 0:02 UTC (permalink / raw)
To: axboe, linux-block, linux-kernel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 43cfbdda5af6 Merge tag 'for-linus-iommufd' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=101e4702580000
kernel config: https://syzkaller.appspot.com/x/.config?x=4660d1ff2985517b
dashboard link: https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0867fa0b89e8/disk-43cfbdda.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/754859270006/vmlinux-43cfbdda.xz
kernel image: https://storage.googleapis.com/syzbot-assets/cd6cca8d06c9/bzImage-43cfbdda.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+cd8a9a308e879a4e2c28@syzkaller.appspotmail.com
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000014: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000000a0-0x00000000000000a7]
CPU: 1 UID: 0 PID: 1174 Comm: kworker/u8:8 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Workqueue: loop2 loop_workfn
RIP: 0010:file_inode include/linux/fs.h:1353 [inline]
RIP: 0010:kiocb_start_write include/linux/fs.h:2763 [inline]
RIP: 0010:lo_rw_aio+0xaa9/0xf00 drivers/block/loop.c:401
Code: 89 33 31 ff 8b 5c 24 44 89 de e8 32 2b 3f fc 85 db 0f 84 ca 00 00 00 48 8b 44 24 58 48 8d 98 a0 00 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 e8 ae a5 fc 4c 89 7c 24 10 48 8b
RSP: 0018:ffffc9000655f620 EFLAGS: 00010206
RAX: 0000000000000014 RBX: 00000000000000a0 RCX: ffff888029649ec0
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc9000655f790 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc9000655f6e3 R11: fffff52000cabede R12: ffff888026c9b090
R13: dffffc0000000000 R14: 0000000000000000 R15: ffff888026c9b0b0
FS: 0000000000000000(0000) GS:ffff88812620f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555591947a68 CR3: 000000005515a000 CR4: 00000000003526f0
Call Trace:
<TASK>
do_req_filebacked drivers/block/loop.c:433 [inline]
loop_handle_cmd drivers/block/loop.c:1925 [inline]
loop_process_work+0x637/0x11b0 drivers/block/loop.c:1960
process_one_work kernel/workqueue.c:3302 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3385
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3466
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:file_inode include/linux/fs.h:1353 [inline]
RIP: 0010:kiocb_start_write include/linux/fs.h:2763 [inline]
RIP: 0010:lo_rw_aio+0xaa9/0xf00 drivers/block/loop.c:401
Code: 89 33 31 ff 8b 5c 24 44 89 de e8 32 2b 3f fc 85 db 0f 84 ca 00 00 00 48 8b 44 24 58 48 8d 98 a0 00 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 e8 ae a5 fc 4c 89 7c 24 10 48 8b
RSP: 0018:ffffc9000655f620 EFLAGS: 00010206
RAX: 0000000000000014 RBX: 00000000000000a0 RCX: ffff888029649ec0
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc9000655f790 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc9000655f6e3 R11: fffff52000cabede R12: ffff888026c9b090
R13: dffffc0000000000 R14: 0000000000000000 R15: ffff888026c9b0b0
FS: 0000000000000000(0000) GS:ffff88812620f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555591947a68 CR3: 000000005515a000 CR4: 00000000003526f0
----------------
Code disassembly (best guess):
0: 89 33 mov %esi,(%rbx)
2: 31 ff xor %edi,%edi
4: 8b 5c 24 44 mov 0x44(%rsp),%ebx
8: 89 de mov %ebx,%esi
a: e8 32 2b 3f fc call 0xfc3f2b41
f: 85 db test %ebx,%ebx
11: 0f 84 ca 00 00 00 je 0xe1
17: 48 8b 44 24 58 mov 0x58(%rsp),%rax
1c: 48 8d 98 a0 00 00 00 lea 0xa0(%rax),%rbx
23: 48 89 d8 mov %rbx,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 42 80 3c 28 00 cmpb $0x0,(%rax,%r13,1) <-- trapping instruction
2f: 74 08 je 0x39
31: 48 89 df mov %rbx,%rdi
34: e8 e8 ae a5 fc call 0xfca5af21
39: 4c 89 7c 24 10 mov %r15,0x10(%rsp)
3e: 48 rex.W
3f: 8b .byte 0x8b
---
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: [PATCH v3 2/2] blk-mq: expose tag starvation counts via debugfs
From: Aaron Tomlin @ 2026-04-18 2:29 UTC (permalink / raw)
To: Jens Axboe, bvanassche
Cc: rostedt, mhiramat, mathieu.desnoyers, johannes.thumshirn, kch,
dlemoal, ritesh.list, loberman, neelx, sean, mproche, chjohnst,
linux-block, linux-kernel, linux-trace-kernel
In-Reply-To: <424110a4-4e14-4e40-af0d-59ca7a30d904@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]
On Fri, Apr 17, 2026 at 02:16:07PM -0600, Jens Axboe wrote:
> On 4/17/26 12:28 PM, Bart Van Assche wrote:
> > On 3/19/26 3:19 PM, Aaron Tomlin wrote:
> >> To guarantee zero performance overhead for production kernels compiled
> >> without debugfs, the underlying atomic_t variables and their associated
> >> increment routines are strictly guarded behind CONFIG_BLK_DEBUG_FS.
> >> When this configuration is disabled, the tracking logic compiles down
> >> to a safe no-op.
> >
> > I don't think that's sufficient. Please use per-cpu counters to
> > minimize the overhead for kernels in which debugfs is enabled.
>
> Agree, this is the usual nonsense of thinking you can hide any overhead
> behind a config option, when in practice production kernels very much DO
> have CONFIG_DEBUGFS enabled.
Hi Bart, Jens,
Thank you both for the candid feedback.
I concede that relying on CONFIG_BLK_DEBUG_FS to mitigate the performance
impact was a short-sighted approach, as you are absolutely right that
debugfs is routinely enabled in modern production environments. The use of
an atomic_t variable in this case would indeed introduce unacceptable cache
line contention under heavy workloads.
I shall address this in the next iteration by transitioning the tracking
logic entirely to per-CPU counters. This will ensure the overhead is
strictly minimised, irrespective of the build configuration.
Thank you again for your time and guidance on this matter.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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