* refactor submit_bio_wait and bio await helpers v3
From: Christoph Hellwig @ 2026-04-07 14:05 UTC (permalink / raw)
To: Jens Axboe
Cc: Carlos Maiolino, Bart Van Assche, Damien Le Moal, linux-block,
linux-xfs
Hi Jens,
this series factors common code between submit_bio_wait and
bio_await_chain into a common helper, and then uses that in XFS
as well instead of open coding such functionality. It also
cleans up the submit or kill logic in the ioctl handlers to
share more code.
There is another places in btrfs that could be refactored to
use this, although it is non-trivial, and I plan to add more
users of this helper to XFS in the future.
Changes since v2:
- spelling fixes
- rename the kick callback to submit
Changes since v1:
- preserve (and extend) setting REQ_SYNC
Diffstat:
block/bio.c | 81 ++++++++++++++++++++++++++++++++-------------------
block/blk-lib.c | 16 +---------
block/blk.h | 2 -
block/ioctl.c | 11 +-----
fs/xfs/xfs_zone_gc.c | 38 +++++++++--------------
include/linux/bio.h | 2 +
6 files changed, 73 insertions(+), 77 deletions(-)
^ permalink raw reply
* Re: [PATCH 3/4] block: add a bio_submit_or_kill helper
From: Christoph Hellwig @ 2026-04-07 13:59 UTC (permalink / raw)
To: Damien Le Moal
Cc: Jens Axboe, Carlos Maiolino, Bart Van Assche, linux-block,
linux-xfs, kbusch
In-Reply-To: <2b2998f6-260d-426d-9ea5-1019bdb8c77d@kernel.org>
On Mon, Apr 06, 2026 at 09:08:16AM +0200, Damien Le Moal wrote:
> > +{
> > + if ((flags & BLKDEV_ZERO_KILLABLE) && fatal_signal_pending(current)) {
> > + bio_await(bio, NULL, bio_endio_cb);
> > + return -EINTR;
>
> This was like this in the previous code, so not big deal, but should we perhaps
> return the bio error if there was one ? And return -EINTR if there was no error.
This only happens when the process was killed. In which case -EINTR as
a syscall return makes sense, independent of any previous error.
^ permalink raw reply
* Re: [PATCH v2 00/10] ublk: add shared memory zero-copy support
From: Jens Axboe @ 2026-04-07 13:44 UTC (permalink / raw)
To: linux-block, Ming Lei; +Cc: Caleb Sander Mateos
In-Reply-To: <20260331153207.3635125-1-ming.lei@redhat.com>
On Tue, 31 Mar 2026 23:31:51 +0800, Ming Lei wrote:
> Add shared memory based zero-copy (UBLK_F_SHMEM_ZC) support for ublk.
>
> The ublk server and its client share a memory region (e.g. memfd or
> hugetlbfs file) via MAP_SHARED mmap. The server registers this region
> with the kernel via UBLK_U_CMD_REG_BUF, which pins the pages and
> builds a PFN maple tree. When I/O arrives, the driver looks up bio
> pages in the maple tree — if they match registered buffer pages, the
> data is used directly without copying.
>
> [...]
Applied, thanks!
[01/10] ublk: add UBLK_U_CMD_REG_BUF/UNREG_BUF control commands
commit: 2fb0ded237bb55dae45bc076666b348fc948ac9e
[02/10] ublk: add PFN-based buffer matching in I/O path
commit: 4d4a512a1f87b156f694d25c800e3d525aa56e8a
[03/10] ublk: enable UBLK_F_SHMEM_ZC feature flag
commit: 08677040a91199175149d1fd465c02e3b3fc768a
[04/10] ublk: eliminate permanent pages[] array from struct ublk_buf
commit: 8a34e88769f617dc980edb5a0079e347bd1b9a89
[05/10] selftests/ublk: add shared memory zero-copy support in kublk
commit: 166b476b8dee61dc6501f6eb91619d28c3430f75
[06/10] selftests/ublk: add UBLK_F_SHMEM_ZC support for loop target
commit: ec20aa44ac2629943c9b2b5524bcb55d778f746c
[07/10] selftests/ublk: add shared memory zero-copy test
commit: 2f1e9468bdcba7e7572e16defd3c516f24281f14
[08/10] selftests/ublk: add hugetlbfs shmem_zc test for loop target
commit: d4866503324c062f70dddfdd2e59957d335fc230
[09/10] selftests/ublk: add filesystem fio verify test for shmem_zc
commit: 12075992c62ee330b2c531fa066b19be21698115
[10/10] selftests/ublk: add read-only buffer registration test
commit: affb5f67d73c1e0bd412e7807a55691502b5679e
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2 00/10] ublk: add shared memory zero-copy support
From: Jens Axboe @ 2026-04-07 13:34 UTC (permalink / raw)
To: Ming Lei, linux-block; +Cc: Caleb Sander Mateos
In-Reply-To: <adRuN7V2KDbTJLqd@fedora>
On 4/6/26 8:38 PM, Ming Lei wrote:
> On Tue, Mar 31, 2026 at 11:31:51PM +0800, Ming Lei wrote:
>> Hello,
>>
>> Add shared memory based zero-copy (UBLK_F_SHMEM_ZC) support for ublk.
>>
>> The ublk server and its client share a memory region (e.g. memfd or
>> hugetlbfs file) via MAP_SHARED mmap. The server registers this region
>> with the kernel via UBLK_U_CMD_REG_BUF, which pins the pages and
>> builds a PFN maple tree. When I/O arrives, the driver looks up bio
>> pages in the maple tree ? if they match registered buffer pages, the
>> data is used directly without copying.
>>
>> Please see details on document added in patch 3.
>>
>> Patches 1-4 implement the kernel side:
>> - buffer register/unregister control commands with PFN coalescing,
>> including read-only buffer support (UBLK_SHMEM_BUF_READ_ONLY)
>> - PFN-based matching in the I/O path, with enforcement that read-only
>> buffers reject non-WRITE requests
>> - UBLK_F_SHMEM_ZC feature flag
>> - eliminate permanent pages[] array from struct ublk_buf; the maple
>> tree already stores PFN ranges, so pages[] becomes temporary
>>
>> Patches 5-10 add kublk (selftest server) support and tests:
>> - hugetlbfs buffer sharing (both kublk and fio mmap the same file)
>> - null target and loop target tests with fio verify
>> - filesystem-level test (ext4 on ublk, fio verify on a file)
>> - read-only buffer registration test (--rdonly_shmem_buf)
>>
>> Changes since V1:
>> - rename struct ublk_buf_reg to struct ublk_shmem_buf_reg, add __u32
>> flags field for extensibility, narrow __u64 len to __u32 (max 4GB
>> per UBLK_SHMEM_ZC_OFF_MASK), remove __u32 reserved (patch 1)
>> - add UBLK_SHMEM_BUF_READ_ONLY flag: pin pages without FOLL_WRITE,
>> enabling registration of write-sealed memfd buffers (patch 1)
>> - use backward-compatible struct reading: memset zero + copy
>> min(header->len, sizeof(struct)) (patch 1)
>> - reorder struct ublk_buf_range fields for better packing (16 bytes
>> vs 24 bytes), change buf_index to unsigned short, add unsigned short
>> flags to store per-range read-only state (patch 1)
>> - enforce read-only buffer semantics in ublk_try_buf_match(): reject
>> non-WRITE requests on read-only buffers since READ I/O needs to
>> write data into the buffer (patch 2)
>> - narrow struct ublk_buf::nr_pages to unsigned int, narrow struct
>> ublk_buf_range::base_offset to unsigned int (patch 1)
>> - add new patch 4: eliminate permanent pages[] array from struct
>> ublk_buf ? recover struct page pointers via pfn_to_page() from the
>> maple tree during unregistration, saving 2MB per 1GB buffer
>> - add UBLK_F_SHMEM_ZC to feat_map in kublk (patch 5)
>> - add new patch 10: read-only buffer registration selftest with
>> --rdonly_shmem_buf option on null target + hugetlbfs
>
> Hello,
>
> Ping...
It generally looks good to me. You have a few mixups of struct
ublk_buf_reg which is the old name, and should be struct
ublk_shmem_buf_reg, and similar a function name changed and the doc not
updated. I'll sort these out while applying.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v3] drbd: use get_random_u64() where appropriate
From: Jens Axboe @ 2026-04-07 12:27 UTC (permalink / raw)
To: Philipp Reisner, Lars Ellenberg, Christoph Böhmwalder,
David Carlier
Cc: drbd-dev, linux-block, linux-kernel
In-Reply-To: <20260405154704.4610-1-devnexen@gmail.com>
On Sun, 05 Apr 2026 16:47:04 +0100, David Carlier wrote:
> Use the typed random integer helpers instead of
> get_random_bytes() when filling a single integer variable.
> The helpers return the value directly, require no pointer
> or size argument, and better express intent.
Applied, thanks!
[1/1] drbd: use get_random_u64() where appropriate
commit: fa0cac9a515877fad856c860ad51107b86ed6c4f
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v3] drbd: use get_random_u64() where appropriate
From: Christoph Böhmwalder @ 2026-04-07 11:03 UTC (permalink / raw)
To: David Carlier
Cc: Philipp Reisner, Lars Ellenberg, Jens Axboe, drbd-dev,
linux-block, linux-kernel
In-Reply-To: <20260405154704.4610-1-devnexen@gmail.com>
On Sun, Apr 05, 2026 at 04:47:04PM +0100, David Carlier wrote:
>Use the typed random integer helpers instead of
>get_random_bytes() when filling a single integer variable.
>The helpers return the value directly, require no pointer
>or size argument, and better express intent.
>
>Signed-off-by: David Carlier <devnexen@gmail.com>
>---
> drivers/block/drbd/drbd_main.c | 4 ++--
> drivers/block/drbd/drbd_nl.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
Maybe I just missed it, but v1 and v2 of this don't seem to exist?
Anyway, the patch itself looks good, thanks.
Reviewed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
^ permalink raw reply
* Re: [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Miguel Ojeda @ 2026-04-07 8:37 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <CAJ-ks9kbHz_KYAXx02vgW1dN2pfb5MFoaSoU1HbJbJg2O8EUaw@mail.gmail.com>
On Mon, Apr 6, 2026 at 5:31 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> You're welcome! Actually it seems the lint was already improved
> upstream, starting with 1.90.0.
>
> Link: https://github.com/rust-lang/rust-clippy/commit/c0dc3b61 [0]
Indeed, I had the PR linked in
https://github.com/Rust-for-Linux/linux/issues/349, and it is nicer,
but it would still fire in a case like this patch :(
So we could conditionally enable it for Rust >= 1.90.0 now that we
have support for that (and allow locally some cases like this one when
they pop up), but it is still simpler to just ignore it (especially
since it can be quite confusing for other developers to see it
triggering).
I think we may want to eventually re-enable it when we use no unstable
language features.
Added:
[ In addition, the lint fired without taking into account the features
that have been enabled in a crate [2]. While this was improved in Rust
1.90.0 [3], it would still fire in a case like this patch. ]
Thanks!
Cheers,
Miguel
^ permalink raw reply
* [PATCH blktests] block/038: cap submit_queues to min(4, nproc) to fix failure on low CPU machines
From: gomid4497 @ 2026-04-07 8:36 UTC (permalink / raw)
To: linux-block, osandov; +Cc: xiliang, gomid4497
Signed-off-by: gomid4497 <rakeshw728@gmail.com>
---
tests/block/038 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/block/038 b/tests/block/038
index 56272be..5cbbd07 100755
--- a/tests/block/038
+++ b/tests/block/038
@@ -28,9 +28,10 @@ null_blk_power_loop() {
null_blk_submit_queues_loop() {
local nullb="$1"
+ local queues=$(( $(nproc) < 4 ? $(nproc) : 4 ))
for ((i = 1; i <= 200; i++)); do
echo 1 > "/sys/kernel/config/nullb/${nullb}/submit_queues"
- echo 4 > "/sys/kernel/config/nullb/${nullb}/submit_queues"
+ echo ${queues} > "/sys/kernel/config/nullb/${nullb}/submit_queues"
done
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [bug report] Oops: general protection fault observed during blktests nvme/fc nvme/057 nvme/058
From: Yi Zhang @ 2026-04-07 8:35 UTC (permalink / raw)
To: open list:NVM EXPRESS DRIVER, linux-block
Cc: Daniel Wagner, Shinichiro Kawasaki
Hi
I reproduced this Oops issue on the latest linux-block/for-next and
v7.0-rc6, please help check it and let me know if you need any
info/test for it, thanks.
reproducer:
blktests nvme/fc nvme/057 nvme/058
console log:
[24778.056260] run blktests nvme/057 at 2026-04-07 03:53:44
[24784.172575] nvme nvme7: Found shared namespace 1, but multipathing
not supported.
[24785.576049] nvme nvme8: Found shared namespace 1, but multipathing
not supported.
[24785.649339] nvme_log_error: 72 callbacks suppressed
[24785.649351] nvme8n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24785.662411] blk_print_req_error: 72 callbacks suppressed
[24785.662417] I/O error, dev nvme8n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24785.676236] buffer_io_error: 67 callbacks suppressed
[24785.676241] Buffer I/O error on dev nvme8n1, logical block 0, async page read
[24785.689844] nvme8n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24785.698047] I/O error, dev nvme8n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24785.706525] Buffer I/O error on dev nvme8n1, logical block 0, async page read
[24785.716133] nvme8n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24785.724182] I/O error, dev nvme8n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24785.732652] Buffer I/O error on dev nvme8n1, logical block 0, async page read
[24785.741196] nvme8n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24785.749242] I/O error, dev nvme8n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24785.757706] Buffer I/O error on dev nvme8n1, logical block 0, async page read
[24785.766193] nvme8n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24785.774462] I/O error, dev nvme8n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24785.782947] Buffer I/O error on dev nvme8n1, logical block 0, async page read
[24785.791432] nvme8n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24785.799769] I/O error, dev nvme8n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24785.808239] Buffer I/O error on dev nvme8n1, logical block 0, async page read
[24785.907390] nvme8n1: I/O Cmd(0x2) @ LBA 2097024, 8 blocks, I/O
Error (sct 0x3 / sc 0x2) MORE
[24785.915982] I/O error, dev nvme8n1, sector 2097024 op 0x0:(READ)
flags 0x80700 phys_seg 1 prio class 2
[24785.926864] nvme8n1: I/O Cmd(0x2) @ LBA 2097024, 8 blocks, I/O
Error (sct 0x3 / sc 0x2) MORE
[24785.935445] I/O error, dev nvme8n1, sector 2097024 op 0x0:(READ)
flags 0x0 phys_seg 1 prio class 2
[24785.944442] Buffer I/O error on dev nvme8n1, logical block 262128,
async page read
[24787.014714] nvme nvme9: Found shared namespace 1, but multipathing
not supported.
[24787.109346] nvme9n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24787.117401] I/O error, dev nvme9n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24787.125928] Buffer I/O error on dev nvme9n1, logical block 0, async page read
[24787.134760] nvme9n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct
0x3 / sc 0x2) MORE
[24787.142808] I/O error, dev nvme9n1, sector 0 op 0x0:(READ) flags
0x0 phys_seg 1 prio class 2
[24787.151340] Buffer I/O error on dev nvme9n1, logical block 0, async page read
[24787.159882] Buffer I/O error on dev nvme9n1, logical block 0, async page read
[24793.253267] nvme nvme6: NVME-FC{0}: transport association event:
transport detected io error
[24793.257123] nvme_log_error: 6 callbacks suppressed
[24793.257128] nvme6n1: I/O Cmd(0x1) @ LBA 543904, 8 blocks, I/O Error
(sct 0x3 / sc 0x70)
[24793.257139] blk_print_req_error: 6 callbacks suppressed
[24793.257143] recoverable transport error, dev nvme6n1, sector 543904
op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 2
[24793.257673] nvme6n1: I/O Cmd(0x1) @ LBA 411480, 8 blocks, I/O Error
(sct 0x3 / sc 0x70)
[24793.257682] recoverable transport error, dev nvme6n1, sector 411480
op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 2
[24793.258044] nvme6n1: I/O Cmd(0x1) @ LBA 710688, 8 blocks, I/O Error
(sct 0x3 / sc 0x70)
[24793.258053] recoverable transport error, dev nvme6n1, sector 710688
op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 2
[24793.261036] nvme6n1: I/O Cmd(0x1) @ LBA 397960, 8 blocks, I/O Error
(sct 0x3 / sc 0x70)
[24793.261047] recoverable transport error, dev nvme6n1, sector 397960
op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 2
[24793.261329] nvme6n1: I/O Cmd(0x1) @ LBA 1591072, 8 blocks, I/O
Error (sct 0x3 / sc 0x70)
[24793.261338] recoverable transport error, dev nvme6n1, sector
1591072 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 2
[24793.261931] nvme nvme6: NVME-FC{0}: resetting controller
[24793.262852] nvme6n1: I/O Cmd(0x1) @ LBA 222192, 8 blocks, I/O Error
(sct 0x3 / sc 0x70)
[24793.262864] recoverable transport error, dev nvme6n1, sector 222192
op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 2
[24793.274891] nvme6n1: I/O Cmd(0x1) @ LBA 1214144, 8 blocks, I/O
Error (sct 0x3 / sc 0x70)
[24793.399106] recoverable transport error, dev nvme6n1, sector
1214144 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 2
[24793.455979] nvme6n1: I/O Cmd(0x1) @ LBA 560192, 8 blocks, I/O Error
(sct 0x3 / sc 0x2) MORE
[24793.456341] nvme6n1: I/O Cmd(0x1) @ LBA 1352744, 8 blocks, I/O
Error (sct 0x3 / sc 0x2) MORE
[24793.456364] nvme6n1: I/O Cmd(0x1) @ LBA 1353024, 8 blocks, I/O
Error (sct 0x3 / sc 0x2) MORE
[24793.456379] I/O error, dev nvme6n1, sector 1353024 op 0x1:(WRITE)
flags 0x8800 phys_seg 1 prio class 2
[24793.456988] I/O error, dev nvme6n1, sector 1913184 op 0x1:(WRITE)
flags 0x8800 phys_seg 1 prio class 2
[24793.457182] I/O error, dev nvme6n1, sector 864944 op 0x1:(WRITE)
flags 0x8800 phys_seg 1 prio class 2
[24793.544368] buffer_io_error: 4 callbacks suppressed
[24793.544379] Buffer I/O error on dev nvme6n1, logical block 0, async page read
[24793.560206] Buffer I/O error on dev nvme6n1, logical block 0, async page read
[24793.569388] Buffer I/O error on dev nvme6n1, logical block 0, async page read
[24793.578024] Buffer I/O error on dev nvme6n1, logical block 0, async page read
[24793.586584] Buffer I/O error on dev nvme6n1, logical block 0, async page read
[24793.595761] Buffer I/O error on dev nvme6n1, logical block 0, async page read
[24793.659221] Buffer I/O error on dev nvme6n1, logical block 262128,
async page read
[24814.210989] Oops: general protection fault, probably for
non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI
[24814.222213] KASAN: null-ptr-deref in range
[0x0000000000000028-0x000000000000002f]
[24814.229789] CPU: 10 UID: 0 PID: 1547 Comm: kworker/u66:2 Not
tainted 7.0.0-rc6+ #1 PREEMPT(full)
[24814.238670] Hardware name: Dell Inc. PowerEdge R6515/07PXPY, BIOS
2.21.1 09/24/2025
[24814.246331] Workqueue: nvmet-wq fcloop_tgt_fcprqst_done_work [nvme_fcloop]
[24814.253219] RIP: 0010:kasan_byte_accessible+0x15/0x30
[24814.258280] Code: 00 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 0f 1f 40 d6 48 b8 00 00 00 00 00 fc ff df 48 c1 ef 03
48 01 c7 <0f> b6 07 3c 07 0f 96 c0 e9 0e d5 04 02 66 66 2e 0f 1f 84 00
00 00
[24814.277034] RSP: 0018:ffffc9000bc9fb68 EFLAGS: 00010286
[24814.282268] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
[24814.289400] RDX: 0000000000000000 RSI: ffffffff89610547 RDI: dffffc0000000005
[24814.296532] RBP: 0000000000000028 R08: 0000000000000001 R09: 0000000000000000
[24814.303666] R10: ffffffff8b7bd367 R11: 0000000000000001 R12: ffffffff89610547
[24814.310799] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
[24814.317939] FS: 0000000000000000(0000) GS:ffff8887d23ca000(0000)
knlGS:0000000000000000
[24814.326033] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[24814.331779] CR2: 0000555867b457e8 CR3: 000000020526f000 CR4: 0000000000350ef0
[24814.338911] Call Trace:
[24814.341365] <TASK>
[24814.343469] __kasan_check_byte+0x13/0x50
[24814.347493] lock_acquire.part.0+0x36/0x260
[24814.351687] ? fcloop_tgt_fcprqst_done_work+0x104/0x200 [nvme_fcloop]
[24814.358135] ? srso_return_thunk+0x5/0x5f
[24814.362153] ? rcu_is_watching+0x15/0xb0
[24814.366082] ? srso_return_thunk+0x5/0x5f
[24814.370102] ? lock_acquire+0x159/0x180
[24814.373955] _raw_spin_lock+0x37/0x80
[24814.377626] ? fcloop_tgt_fcprqst_done_work+0x104/0x200 [nvme_fcloop]
[24814.384073] fcloop_tgt_fcprqst_done_work+0x104/0x200 [nvme_fcloop]
[24814.390351] process_one_work+0xd98/0x1390
[24814.394465] ? __pfx_process_one_work+0x10/0x10
[24814.399017] ? srso_return_thunk+0x5/0x5f
[24814.403039] worker_thread+0x60b/0x1000
[24814.406895] ? __pfx_worker_thread+0x10/0x10
[24814.411171] kthread+0x36c/0x470
[24814.414414] ? _raw_spin_unlock_irq+0x28/0x50
[24814.418780] ? __pfx_kthread+0x10/0x10
[24814.422546] ret_from_fork+0x5dc/0x8e0
[24814.426306] ? __pfx_ret_from_fork+0x10/0x10
[24814.430588] ? srso_return_thunk+0x5/0x5f
[24814.434605] ? __switch_to+0x524/0xf50
[24814.438367] ? __switch_to_asm+0x39/0x70
[24814.442302] ? __pfx_kthread+0x10/0x10
[24814.446065] ret_from_fork_asm+0x1a/0x30
[24814.450012] </TASK>
[24814.452206] Modules linked in: nvme_fcloop nvmet_fc nvme_fc nvmet
nvme_fabrics platform_profile dell_wmi dell_smbios amd_atl
intel_rapl_msr intel_rapl_common amd64_edac sparse_keymap edac_mce_amd
rfkill video vfat dcdbas fat kvm_amd cdc_ether usbnet mii kvm
irqbypass dell_wmi_descriptor wmi_bmof rapl acpi_cpufreq pcspkr
ipmi_ssif i2c_piix4 ptdma k10temp i2c_smbus acpi_power_meter ipmi_si
acpi_ipmi ipmi_devintf ipmi_msghandler sg loop fuse xfs sd_mod nvme
ahci mgag200 libahci i2c_algo_bit mpt3sas ghash_clmulni_intel
nvme_core tg3 raid_class libata nvme_keyring ccp nvme_auth
scsi_transport_sas sp5100_tco wmi sunrpc dm_mirror dm_region_hash
dm_log dm_mod i2c_dev nfnetlink [last unloaded: nvmet_fc]
[24814.514133] ---[ end trace 0000000000000000 ]---
[24814.691561] RIP: 0010:kasan_byte_accessible+0x15/0x30
[24814.696869] Code: 00 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 0f 1f 40 d6 48 b8 00 00 00 00 00 fc ff df 48 c1 ef 03
48 01 c7 <0f> b6 07 3c 07 0f 96 c0 e9 0e d5 04 02 66 66 2e 0f 1f 84 00
00 00
[24814.715839] RSP: 0018:ffffc9000bc9fb68 EFLAGS: 00010286
[24814.721279] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
[24814.728651] RDX: 0000000000000000 RSI: ffffffff89610547 RDI: dffffc0000000005
[24814.736122] RBP: 0000000000000028 R08: 0000000000000001 R09: 0000000000000000
[24814.743575] R10: ffffffff8b7bd367 R11: 0000000000000001 R12: ffffffff89610547
[24814.750962] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
[24814.758254] FS: 0000000000000000(0000) GS:ffff8887d23ca000(0000)
knlGS:0000000000000000
[24814.766373] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[24814.772139] CR2: 0000555867b457e8 CR3: 000000020526f000 CR4: 0000000000350ef0
[24814.779291] Kernel panic - not syncing: Fatal exception
[24814.785098] Kernel Offset: 0x5600000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[24814.976844] ---[ end Kernel panic - not syncing: Fatal exception ]---
--
Best Regards,
Yi Zhang
^ permalink raw reply
* Re: [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page
From: Naman Jain @ 2026-04-07 7:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Chaitanya Kulkarni, John Hubbard, Logan Gunthorpe,
linux-kernel, linux-block, Saurabh Sengar, Long Li,
Michael Kelley
In-Reply-To: <20260407055247.GA6405@lst.de>
On 4/7/2026 11:22 AM, Christoph Hellwig wrote:
>> - if (!zone_device_pages_have_same_pgmap(bv->bv_page, page))
>> + if (!zone_device_pages_compatible(bv->bv_page, page))
>> return 0;
>> -
>> - if (bvec_try_merge_hw_page(q, bv, page, len, offset)) {
>> + if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
>> + bvec_try_merge_hw_page(q, bv, page, len, offset)) {
>
> We still can't merge merge pages with different P2P pgmaps into the
> same request.
>
> So the zone_device_pages_have_same_pgmap check should go into
> zone_device_pages_compatible and we need to stop building the bio
> as well in that case.
Ok, so rest all things same, from my last email, but my previous
compatible function would look like this:
static inline bool zone_device_pages_compatible(const struct page *a,
const struct page *b)
{
if (is_pci_p2pdma_page(a) || is_pci_p2pdma_page(b))
return zone_device_pages_have_same_pgmap(a, b);
return true;
}
This would prevent two P2PDMA pages from different pgmaps (different PCI
devices) passing the compatible check and both get added to the bio.
Please correct me if that is not what you meant. I'll wait for a couple
more days and send the next version with this, and we can review this again.
Thanks for your inputs.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page
From: Christoph Hellwig @ 2026-04-07 5:52 UTC (permalink / raw)
To: Naman Jain
Cc: Christoph Hellwig, Jens Axboe, Chaitanya Kulkarni, John Hubbard,
Logan Gunthorpe, linux-kernel, linux-block, Saurabh Sengar,
Long Li, Michael Kelley
In-Reply-To: <d48427c2-9aa3-42a2-a8d7-43a7a3b3b685@linux.microsoft.com>
> - if (!zone_device_pages_have_same_pgmap(bv->bv_page, page))
> + if (!zone_device_pages_compatible(bv->bv_page, page))
> return 0;
> -
> - if (bvec_try_merge_hw_page(q, bv, page, len, offset)) {
> + if (zone_device_pages_have_same_pgmap(bv->bv_page, page) &&
> + bvec_try_merge_hw_page(q, bv, page, len, offset)) {
We still can't merge merge pages with different P2P pgmaps into the
same request.
So the zone_device_pages_have_same_pgmap check should go into
zone_device_pages_compatible and we need to stop building the bio
as well in that case.
^ permalink raw reply
* Re: [RFC] block/nvme: exploring asynchronous durability notification semantics
From: Christoph Hellwig @ 2026-04-07 5:48 UTC (permalink / raw)
To: Esteban Cerutti; +Cc: linux-kernel, linux-block, linux-nvme
In-Reply-To: <ac7eHEnFQlLN-vDy@yanara>
On Thu, Apr 02, 2026 at 06:22:36PM -0300, Esteban Cerutti wrote:
> Today, a successful write completion indicates command execution,
> but not necessarily physical persistence to non-volatile media unless
> FUA or Flush is used. This forces the kernel and filesystems to assume
> worst-case durability behavior and rely on synchronous flushes and
> barriers for safety.
Nothing relies on synchronous flushes, and we killed barriers a long
time ago. FUA does as you say provide persistence notifications and
is heavily used for the (relatively rare) case where it matters.
> - Normal completion continues to signal execution.
> - The device assigns a persistence token ID.
> - When the data is physically committed to non-volatile media,
> the device emits an asynchronous durability confirmation
> referencing that token.
>
> This would decouple execution throughput from durability
> confirmation and potentially allow filesystems to close journal
> transactions only upon confirmed persistence, without forcing
> synchronous flush fences.
This is so complex that it's not going to work in practice.
You've also failed to explain where you think your model is actually
helping to improve clearly identifiable workloads. Note that all of
this would be limited to consumer hardware anyway, as volatile write
caches aren't really a thing for higher end hardware.
^ permalink raw reply
* Re: [PATCH blktests] src/dio-offsets.c: Fix err() usage
From: Shinichiro Kawasaki @ 2026-04-07 3:37 UTC (permalink / raw)
To: Bart Van Assche; +Cc: Damien Le Moal, linux-block@vger.kernel.org, Keith Busch
In-Reply-To: <020e64e2-8a2c-4e91-ac4e-21801fe5216f@acm.org>
On Apr 06, 2026 / 06:51, Bart Van Assche wrote:
> On 4/4/26 1:35 AM, Shinichiro Kawasaki wrote:
> > One thing I found is that one more err(EIO,...) is left in __compare() after
> > applying the patch. Should we convert it also into err_errno()? If so, I will
> > fold-in the hunk below.
> >
> > diff --git a/src/dio-offsets.c b/src/dio-offsets.c
> > index 9fc7b92..c40ce68 100644
> > --- a/src/dio-offsets.c
> > +++ b/src/dio-offsets.c
> > @@ -131,7 +131,7 @@ static void __compare(void *a, void *b, size_t size, const char *test)
> > {
> > if (!memcmp(a, b, size))
> > return;
> > - err(EIO, "%s: data corruption", test);
> > + err_errno(EIO, "%s: data corruption", test);
> > }
> > #define compare(a, b, size) __compare(a, b, size, __func__)
>
> Folding in this change sounds good to me.
Thanks for the response. I applied the patch folding in the change.
^ permalink raw reply
* Re: [PATCH v2 00/10] ublk: add shared memory zero-copy support
From: Ming Lei @ 2026-04-07 2:38 UTC (permalink / raw)
To: Jens Axboe, linux-block; +Cc: Caleb Sander Mateos
In-Reply-To: <20260331153207.3635125-1-ming.lei@redhat.com>
On Tue, Mar 31, 2026 at 11:31:51PM +0800, Ming Lei wrote:
> Hello,
>
> Add shared memory based zero-copy (UBLK_F_SHMEM_ZC) support for ublk.
>
> The ublk server and its client share a memory region (e.g. memfd or
> hugetlbfs file) via MAP_SHARED mmap. The server registers this region
> with the kernel via UBLK_U_CMD_REG_BUF, which pins the pages and
> builds a PFN maple tree. When I/O arrives, the driver looks up bio
> pages in the maple tree — if they match registered buffer pages, the
> data is used directly without copying.
>
> Please see details on document added in patch 3.
>
> Patches 1-4 implement the kernel side:
> - buffer register/unregister control commands with PFN coalescing,
> including read-only buffer support (UBLK_SHMEM_BUF_READ_ONLY)
> - PFN-based matching in the I/O path, with enforcement that read-only
> buffers reject non-WRITE requests
> - UBLK_F_SHMEM_ZC feature flag
> - eliminate permanent pages[] array from struct ublk_buf; the maple
> tree already stores PFN ranges, so pages[] becomes temporary
>
> Patches 5-10 add kublk (selftest server) support and tests:
> - hugetlbfs buffer sharing (both kublk and fio mmap the same file)
> - null target and loop target tests with fio verify
> - filesystem-level test (ext4 on ublk, fio verify on a file)
> - read-only buffer registration test (--rdonly_shmem_buf)
>
> Changes since V1:
> - rename struct ublk_buf_reg to struct ublk_shmem_buf_reg, add __u32
> flags field for extensibility, narrow __u64 len to __u32 (max 4GB
> per UBLK_SHMEM_ZC_OFF_MASK), remove __u32 reserved (patch 1)
> - add UBLK_SHMEM_BUF_READ_ONLY flag: pin pages without FOLL_WRITE,
> enabling registration of write-sealed memfd buffers (patch 1)
> - use backward-compatible struct reading: memset zero + copy
> min(header->len, sizeof(struct)) (patch 1)
> - reorder struct ublk_buf_range fields for better packing (16 bytes
> vs 24 bytes), change buf_index to unsigned short, add unsigned short
> flags to store per-range read-only state (patch 1)
> - enforce read-only buffer semantics in ublk_try_buf_match(): reject
> non-WRITE requests on read-only buffers since READ I/O needs to
> write data into the buffer (patch 2)
> - narrow struct ublk_buf::nr_pages to unsigned int, narrow struct
> ublk_buf_range::base_offset to unsigned int (patch 1)
> - add new patch 4: eliminate permanent pages[] array from struct
> ublk_buf — recover struct page pointers via pfn_to_page() from the
> maple tree during unregistration, saving 2MB per 1GB buffer
> - add UBLK_F_SHMEM_ZC to feat_map in kublk (patch 5)
> - add new patch 10: read-only buffer registration selftest with
> --rdonly_shmem_buf option on null target + hugetlbfs
Hello,
Ping...
thanks,
Ming
^ permalink raw reply
* Re: [PATCH] drbd: remove DRBD_GENLA_F_MANDATORY flag handling
From: Jens Axboe @ 2026-04-07 2:22 UTC (permalink / raw)
To: Christoph Böhmwalder
Cc: drbd-dev, linux-kernel, Lars Ellenberg, Philipp Reisner,
linux-block, Johannes Berg, Jakub Kicinski
In-Reply-To: <20260403132953.2248751-1-christoph.boehmwalder@linbit.com>
On Fri, 03 Apr 2026 15:29:53 +0200, Christoph Böhmwalder wrote:
> DRBD used a custom mechanism to mark netlink attributes as "mandatory":
> bit 14 of nla_type was repurposed as DRBD_GENLA_F_MANDATORY. Attributes
> sent from userspace that had this bit present and that were unknown
> to the kernel would lead to an error.
>
> Since commit ef6243acb478 ("genetlink: optionally validate strictly/dumps"),
> the generic netlink layer rejects unknown top-level attributes when
> strict validation is enabled. DRBD never opted out of strict
> validation, so unknown top-level attributes are already rejected by
> the netlink core.
>
> [...]
Applied, thanks!
[1/1] drbd: remove DRBD_GENLA_F_MANDATORY flag handling
commit: a9c4b1d37622ed01b75f94a4f68cf55f33153a31
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [bug report]nvmet_auth kmemleak observed during blktests
From: Alistair Francis @ 2026-04-07 1:23 UTC (permalink / raw)
To: yi.zhang@redhat.com, mlombard@arkamax.eu
Cc: hch@lst.de, sagi@grimberg.me, hare@suse.de,
linux-nvme@lists.infradead.org, Shinichiro Kawasaki,
Wilfred Mallawa, linux-block@vger.kernel.org, kbusch@kernel.org
In-Reply-To: <CAHj4cs9XrhqiVS81ceO_m70dU9xVB_aoC3HDZ-8ABeDow6eWog@mail.gmail.com>
On Tue, 2026-04-07 at 08:54 +0800, Yi Zhang wrote:
> On Fri, Apr 3, 2026 at 5:21 PM Maurizio Lombardi
> <mlombard@arkamax.eu> wrote:
> >
> > On Fri Apr 3, 2026 at 10:46 AM CEST, Yi Zhang wrote:
> > > Hi
> > >
> > > I found the following kmemleak during blktests on the
> > > linux-block/for-next, please help check it and let me know if you
> > > need
> > > any test/info for it, thanks.
> > >
> > > commit:
> > > aac56c7b77fa (HEAD -> for-next, origin/for-next) Merge branch
> > > 'for-7.1/io_uring' into for-next
> > >
> > > reproducer:
> > > nvme_trtype=loop ./check nvme/041 nvme/042 nvme/043 nvme/044
> > > nvme/045
> > > nvme/051 nvme/052
> > >
> > > kmemleak:
> > > unreferenced object 0xff11000305c48240 (size 32):
> > > comm "kworker/u48:3", pid 123223, jiffies 4401374163
> > > hex dump (first 32 bytes):
> > > 30 1e 78 66 9b 04 e7 4a d5 d7 a3 a2 ab 1f f1 22
> > > 0.xf...J......."
> > > 11 4a aa 11 b5 f7 fa f6 24 a6 17 11 e6 f8 e7 dc
> > > .J......$.......
> > > backtrace (crc 58405ce8):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> >
> > Maybe this has been introduced by commit 2e6eb6b277f5
> > ("nvmet-tcp: Don't free SQ on authentication success")
> >
> > If nvmet_execute_auth_receive() gets called twice and executes
> > nvmet_auth_challenge(), the dhchap_c1 pointer is leaked.
>
> Thanks Maurizio.
>
> The kmemleak cannot be reproduced now after reverting that commit.
That's not the fix though, as that breaks REPLACETLSPSK.
Can you supply more logs to narrow down a fix?
Alistair
>
> >
> > Maurizio
> >
> > > unreferenced object 0xff1100027be14c00 (size 256):
> > > comm "kworker/u48:3", pid 123223, jiffies 4401374168
> > > hex dump (first 32 bytes):
> > > 30 96 ec 83 33 bb fc 41 ec 81 70 14 1e ad 32 fd
> > > 0...3..A..p...2.
> > > 39 b8 ca 9c 99 22 ff 28 f0 80 f3 e0 1d 82 36 a9
> > > 9....".(......6.
> > > backtrace (crc e365275d):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff11000305c48d40 (size 32):
> > > comm "kworker/u48:3", pid 123223, jiffies 4401374170
> > > hex dump (first 32 bytes):
> > > c0 8b 24 c4 c1 5a 37 d1 fc 49 ec 3e 44 05 7e 19
> > > ..$..Z7..I.>D.~.
> > > 70 39 6a d0 53 22 6d 23 fc b9 94 83 e3 3a 60 e2
> > > p9j.S"m#.....:`.
> > > backtrace (crc 8284cf12):
> > > __kmalloc_node_track_caller_noprof+0x637/0x880
> > > kmemdup_noprof+0x22/0x50
> > > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff1100016dd8c7c0 (size 32):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374600
> > > hex dump (first 32 bytes):
> > > 21 1e e5 a0 b9 e6 a0 6b 85 cb 62 ff 30 d6 21 0f
> > > !......k..b.0.!.
> > > 05 89 bc 6a 44 fe 2a c4 bd 35 23 59 6c 56 2b 2e
> > > ...jD.*..5#YlV+.
> > > backtrace (crc e32fd56c):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff11000255549600 (size 256):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374604
> > > hex dump (first 32 bytes):
> > > 11 1a 6e 99 d1 bc ae 48 5d aa f1 74 62 30 68 c4
> > > ..n....H]..tb0h.
> > > 07 9f 31 dc 83 a4 a4 92 47 18 9c 04 1e 7d 68 c1
> > > ..1.....G....}h.
> > > backtrace (crc db3ad817):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff1100016dd8cc00 (size 32):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374609
> > > hex dump (first 32 bytes):
> > > 51 ff e9 8e 10 6b b4 b3 3f 6c 7d f2 74 eb 42 98
> > > Q....k..?l}.t.B.
> > > 6c f8 ab ec 10 d6 e8 0f 02 79 4a e4 ec b2 ce ed
> > > l........yJ.....
> > > backtrace (crc 7099040d):
> > > __kmalloc_node_track_caller_noprof+0x637/0x880
> > > kmemdup_noprof+0x22/0x50
> > > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff1100025554a800 (size 256):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374633
> > > hex dump (first 32 bytes):
> > > eb a9 ed 0e b7 42 c6 6c 48 ee 56 29 a4 8a 99 18
> > > .....B.lH.V)....
> > > 1c 90 2a 53 22 7a ee 5a c0 6e 60 43 5b 33 a1 d2
> > > ..*S"z.Z.n`C[3..
> > > backtrace (crc 3ce24e58):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff11000267237a80 (size 32):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374635
> > > hex dump (first 32 bytes):
> > > 20 25 77 95 60 f2 19 5a 09 20 2c 25 8b 04 2a 4b %w.`..Z.
> > > ,%..*K
> > > b9 53 8e 10 39 b9 07 0d e0 fc 93 3f 82 50 86 0c
> > > .S..9......?.P..
> > > backtrace (crc 3f42440d):
> > > __kmalloc_node_track_caller_noprof+0x637/0x880
> > > kmemdup_noprof+0x22/0x50
> > > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff11000138f46e40 (size 32):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374654
> > > hex dump (first 32 bytes):
> > > 2d da 99 66 3b e7 d6 65 aa d7 1f a6 51 b4 ab 19 -
> > > ..f;..e....Q...
> > > 46 d7 30 0d 12 fd 55 90 c4 6a 4a 7a b8 55 7f 4f
> > > F.0...U..jJz.U.O
> > > backtrace (crc 3ab35d56):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff11000126860400 (size 256):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374658
> > > hex dump (first 32 bytes):
> > > cb 48 8c 49 58 82 bd fd 21 5b e4 a5 5b 5e 7b 8b
> > > .H.IX...![..[^{.
> > > 48 6a 47 3e 9f b7 76 06 c8 47 6a 5f 3e b4 20 15
> > > HjG>..v..Gj_>. .
> > > backtrace (crc b164cda1):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff11000138f468c0 (size 32):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374662
> > > hex dump (first 32 bytes):
> > > 01 dd af 3b af a0 f8 ec 61 80 c4 aa ad 56 9a 27
> > > ...;....a....V.'
> > > d4 f9 f9 8d 98 64 ce 5a 81 e2 14 e0 e3 5c 79 97
> > > .....d.Z.....\y.
> > > backtrace (crc b24f43c2):
> > > __kmalloc_node_track_caller_noprof+0x637/0x880
> > > kmemdup_noprof+0x22/0x50
> > > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> > > unreferenced object 0xff11000185c80580 (size 64):
> > > comm "kworker/u48:2", pid 139664, jiffies 4401374716
> > > hex dump (first 32 bytes):
> > > bf a4 73 5a 5c a7 d7 8e f7 6e f9 39 3a 94 66 a4
> > > ..sZ\....n.9:.f.
> > > 8e f9 bc f6 9a 23 ac dc c8 71 85 ef 09 4c ac 38
> > > .....#...q...L.8
> > > backtrace (crc 70f5e8bf):
> > > __kmalloc_noprof+0x635/0x870
> > > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > > process_one_work+0xd98/0x1390
> > > worker_thread+0x60b/0x1000
> > > kthread+0x36c/0x470
> > > ret_from_fork+0x5dc/0x8e0
> > > ret_from_fork_asm+0x1a/0x30
> >
>
^ permalink raw reply
* Re: [PATCH v2 00/33] rust: bump minimum Rust and `bindgen` versions
From: Miguel Ojeda @ 2026-04-07 1:15 UTC (permalink / raw)
To: John Hubbard
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <efe61810-2b28-4acd-b69f-d577042c0b62@nvidia.com>
On Mon, Apr 6, 2026 at 9:07 PM John Hubbard <jhubbard@nvidia.com> wrote:
>
> That's what I thought I recalled, too. Weird that it is not in rust-next
> already, though.
It is normal -- in the kernel back merges are generally to be avoided.
Cheers,
Miguel
^ permalink raw reply
* Re: [bug report]nvmet_auth kmemleak observed during blktests
From: Yi Zhang @ 2026-04-07 0:54 UTC (permalink / raw)
To: Maurizio Lombardi, Alistair Francis
Cc: linux-block, open list:NVM EXPRESS DRIVER, Shinichiro Kawasaki,
Christoph Hellwig, Hannes Reinecke, wilfred.mallawa,
Sagi Grimberg, Keith Busch
In-Reply-To: <DHJEQZRGEMDX.1KX53DW8BCUPC@arkamax.eu>
On Fri, Apr 3, 2026 at 5:21 PM Maurizio Lombardi <mlombard@arkamax.eu> wrote:
>
> On Fri Apr 3, 2026 at 10:46 AM CEST, Yi Zhang wrote:
> > Hi
> >
> > I found the following kmemleak during blktests on the
> > linux-block/for-next, please help check it and let me know if you need
> > any test/info for it, thanks.
> >
> > commit:
> > aac56c7b77fa (HEAD -> for-next, origin/for-next) Merge branch
> > 'for-7.1/io_uring' into for-next
> >
> > reproducer:
> > nvme_trtype=loop ./check nvme/041 nvme/042 nvme/043 nvme/044 nvme/045
> > nvme/051 nvme/052
> >
> > kmemleak:
> > unreferenced object 0xff11000305c48240 (size 32):
> > comm "kworker/u48:3", pid 123223, jiffies 4401374163
> > hex dump (first 32 bytes):
> > 30 1e 78 66 9b 04 e7 4a d5 d7 a3 a2 ab 1f f1 22 0.xf...J......."
> > 11 4a aa 11 b5 f7 fa f6 24 a6 17 11 e6 f8 e7 dc .J......$.......
> > backtrace (crc 58405ce8):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
>
> Maybe this has been introduced by commit 2e6eb6b277f5
> ("nvmet-tcp: Don't free SQ on authentication success")
>
> If nvmet_execute_auth_receive() gets called twice and executes
> nvmet_auth_challenge(), the dhchap_c1 pointer is leaked.
Thanks Maurizio.
The kmemleak cannot be reproduced now after reverting that commit.
>
> Maurizio
>
> > unreferenced object 0xff1100027be14c00 (size 256):
> > comm "kworker/u48:3", pid 123223, jiffies 4401374168
> > hex dump (first 32 bytes):
> > 30 96 ec 83 33 bb fc 41 ec 81 70 14 1e ad 32 fd 0...3..A..p...2.
> > 39 b8 ca 9c 99 22 ff 28 f0 80 f3 e0 1d 82 36 a9 9....".(......6.
> > backtrace (crc e365275d):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff11000305c48d40 (size 32):
> > comm "kworker/u48:3", pid 123223, jiffies 4401374170
> > hex dump (first 32 bytes):
> > c0 8b 24 c4 c1 5a 37 d1 fc 49 ec 3e 44 05 7e 19 ..$..Z7..I.>D.~.
> > 70 39 6a d0 53 22 6d 23 fc b9 94 83 e3 3a 60 e2 p9j.S"m#.....:`.
> > backtrace (crc 8284cf12):
> > __kmalloc_node_track_caller_noprof+0x637/0x880
> > kmemdup_noprof+0x22/0x50
> > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff1100016dd8c7c0 (size 32):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374600
> > hex dump (first 32 bytes):
> > 21 1e e5 a0 b9 e6 a0 6b 85 cb 62 ff 30 d6 21 0f !......k..b.0.!.
> > 05 89 bc 6a 44 fe 2a c4 bd 35 23 59 6c 56 2b 2e ...jD.*..5#YlV+.
> > backtrace (crc e32fd56c):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff11000255549600 (size 256):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374604
> > hex dump (first 32 bytes):
> > 11 1a 6e 99 d1 bc ae 48 5d aa f1 74 62 30 68 c4 ..n....H]..tb0h.
> > 07 9f 31 dc 83 a4 a4 92 47 18 9c 04 1e 7d 68 c1 ..1.....G....}h.
> > backtrace (crc db3ad817):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff1100016dd8cc00 (size 32):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374609
> > hex dump (first 32 bytes):
> > 51 ff e9 8e 10 6b b4 b3 3f 6c 7d f2 74 eb 42 98 Q....k..?l}.t.B.
> > 6c f8 ab ec 10 d6 e8 0f 02 79 4a e4 ec b2 ce ed l........yJ.....
> > backtrace (crc 7099040d):
> > __kmalloc_node_track_caller_noprof+0x637/0x880
> > kmemdup_noprof+0x22/0x50
> > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff1100025554a800 (size 256):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374633
> > hex dump (first 32 bytes):
> > eb a9 ed 0e b7 42 c6 6c 48 ee 56 29 a4 8a 99 18 .....B.lH.V)....
> > 1c 90 2a 53 22 7a ee 5a c0 6e 60 43 5b 33 a1 d2 ..*S"z.Z.n`C[3..
> > backtrace (crc 3ce24e58):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff11000267237a80 (size 32):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374635
> > hex dump (first 32 bytes):
> > 20 25 77 95 60 f2 19 5a 09 20 2c 25 8b 04 2a 4b %w.`..Z. ,%..*K
> > b9 53 8e 10 39 b9 07 0d e0 fc 93 3f 82 50 86 0c .S..9......?.P..
> > backtrace (crc 3f42440d):
> > __kmalloc_node_track_caller_noprof+0x637/0x880
> > kmemdup_noprof+0x22/0x50
> > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff11000138f46e40 (size 32):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374654
> > hex dump (first 32 bytes):
> > 2d da 99 66 3b e7 d6 65 aa d7 1f a6 51 b4 ab 19 -..f;..e....Q...
> > 46 d7 30 0d 12 fd 55 90 c4 6a 4a 7a b8 55 7f 4f F.0...U..jJz.U.O
> > backtrace (crc 3ab35d56):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff11000126860400 (size 256):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374658
> > hex dump (first 32 bytes):
> > cb 48 8c 49 58 82 bd fd 21 5b e4 a5 5b 5e 7b 8b .H.IX...![..[^{.
> > 48 6a 47 3e 9f b7 76 06 c8 47 6a 5f 3e b4 20 15 HjG>..v..Gj_>. .
> > backtrace (crc b164cda1):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_ctrl_sesskey+0xfa/0x3a0 [nvmet]
> > nvmet_auth_reply+0x436/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff11000138f468c0 (size 32):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374662
> > hex dump (first 32 bytes):
> > 01 dd af 3b af a0 f8 ec 61 80 c4 aa ad 56 9a 27 ...;....a....V.'
> > d4 f9 f9 8d 98 64 ce 5a 81 e2 14 e0 e3 5c 79 97 .....d.Z.....\y.
> > backtrace (crc b24f43c2):
> > __kmalloc_node_track_caller_noprof+0x637/0x880
> > kmemdup_noprof+0x22/0x50
> > nvmet_auth_reply+0x2ba/0xd00 [nvmet]
> > nvmet_execute_auth_send+0xc7f/0x14f0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
> > unreferenced object 0xff11000185c80580 (size 64):
> > comm "kworker/u48:2", pid 139664, jiffies 4401374716
> > hex dump (first 32 bytes):
> > bf a4 73 5a 5c a7 d7 8e f7 6e f9 39 3a 94 66 a4 ..sZ\....n.9:.f.
> > 8e f9 bc f6 9a 23 ac dc c8 71 85 ef 09 4c ac 38 .....#...q...L.8
> > backtrace (crc 70f5e8bf):
> > __kmalloc_noprof+0x635/0x870
> > nvmet_auth_challenge+0x329/0x9f0 [nvmet]
> > nvmet_execute_auth_receive+0x381/0x7b0 [nvmet]
> > process_one_work+0xd98/0x1390
> > worker_thread+0x60b/0x1000
> > kthread+0x36c/0x470
> > ret_from_fork+0x5dc/0x8e0
> > ret_from_fork_asm+0x1a/0x30
>
--
Best Regards,
Yi Zhang
^ permalink raw reply
* Re: [syzbot] [block?] [trace?] INFO: task hung in blk_trace_startstop
From: syzbot @ 2026-04-06 19:55 UTC (permalink / raw)
To: axboe, linux-block, linux-kernel, linux-trace-kernel,
mathieu.desnoyers, mhiramat, rostedt, syzkaller-bugs
In-Reply-To: <691367ae.a70a0220.22f260.0141.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 591cd656a1bf Linux 7.0-rc7
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=129136ba580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6754c86e8d9e4c91
dashboard link: https://syzkaller.appspot.com/bug?extid=774863666ef5b025c9d0
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=1268ad4e580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1580b3da580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6382829d7cc5/disk-591cd656.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/17a325d524d5/vmlinux-591cd656.xz
kernel image: https://storage.googleapis.com/syzbot-assets/0a06ea295210/bzImage-591cd656.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+774863666ef5b025c9d0@syzkaller.appspotmail.com
INFO: task syz.2.19:6128 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.2.19 state:D stack:27960 pid:6128 tgid:6125 ppid:5955 task_flags:0x400040 flags:0x00080002
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5298 [inline]
__schedule+0x15dd/0x52d0 kernel/sched/core.c:6911
__schedule_loop kernel/sched/core.c:6993 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7008
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7065
__mutex_lock_common kernel/locking/mutex.c:692 [inline]
__mutex_lock+0x7fe/0x1300 kernel/locking/mutex.c:776
blk_debugfs_lock_nomemsave block/blk.h:740 [inline]
blk_trace_startstop+0x8f/0x610 kernel/trace/blktrace.c:903
blk_trace_ioctl+0x314/0x920 kernel/trace/blktrace.c:949
blkdev_common_ioctl+0x13a7/0x3250 block/ioctl.c:724
blkdev_ioctl+0x528/0x740 block/ioctl.c:798
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7f6ab9c819
RSP: 002b:00007f7f6baad028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f7f6ae16090 RCX: 00007f7f6ab9c819
RDX: 0000000000000000 RSI: 0000000000001274 RDI: 0000000000000003
RBP: 00007f7f6ac32c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
---
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 v2 00/33] rust: bump minimum Rust and `bindgen` versions
From: John Hubbard @ 2026-04-06 19:07 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <CANiq72n4tmTzqbcHCnzUBFyLVmJzB-AJng_1FgELJCWr7hDg4A@mail.gmail.com>
On 4/6/26 12:01 PM, Miguel Ojeda wrote:
> On Mon, Apr 6, 2026 at 8:51 PM John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> Looks good from the perspective of this patchset. I am seeing
>> one remaining problem that we previously came up with a fix for,
>> so I expect that that fix is staged in another branch. But in
>> case it's not, here is the report:
>>
>> On today's rust-next, using rustc 1.85.0, at commit 232e79c72f57
>> ("rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0"):
>>
>> CLIPPY [M] drivers/gpu/drm/nova/nova.o
>> warning: consider removing unnecessary double parentheses
>> --> rust/doctests_kernel_generated.rs:4240:14
>> |
>> 4240 | pr_info!("The policy details are: {:?}\n", (policy.cpu(), policy.cur()));
>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> |
>> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_parens
>> = note: `-W clippy::double-parens` implied by `-W clippy::all`
>> = help: to override `-W clippy::all` add `#[allow(clippy::double_parens)]`
>>
>> warning: 1 warning emitted
>
> That is already fixed and in mainline: 487f9b3dc6e5 ("rust: cpufreq:
> suppress clippy::double_parens in Policy doctest").
>
That's what I thought I recalled, too. Weird that it is not in rust-next
already, though.
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v2] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
From: Jens Axboe @ 2026-04-06 19:03 UTC (permalink / raw)
To: Yuto Ohnuki
Cc: Yu Kuai, Nilay Shroff, Ming Lei, linux-block, linux-kernel,
syzbot+71fcf20f7c1e5043d78c
In-Reply-To: <20260316070358.65225-2-ytohnuki@amazon.com>
On Mon, 16 Mar 2026 07:03:59 +0000, Yuto Ohnuki wrote:
> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
> wbt_alloc() and wbt_init(). However, both are expected failure paths:
>
> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)
> - wbt_init() can fail with -EBUSY if wbt is already registered
>
> syzbot triggers this by injecting memory allocation failures during MTD
> partition creation via ioctl(BLKPG), causing a spurious warning.
>
> [...]
Applied, thanks!
[1/1] blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()
commit: e9b004ff83067cdf96774b45aea4b239ace99a2f
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2 00/33] rust: bump minimum Rust and `bindgen` versions
From: Miguel Ojeda @ 2026-04-06 19:01 UTC (permalink / raw)
To: John Hubbard
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <cf28afe0-ede5-4d1a-9824-65a1448f8161@nvidia.com>
On Mon, Apr 6, 2026 at 8:51 PM John Hubbard <jhubbard@nvidia.com> wrote:
>
> Looks good from the perspective of this patchset. I am seeing
> one remaining problem that we previously came up with a fix for,
> so I expect that that fix is staged in another branch. But in
> case it's not, here is the report:
>
> On today's rust-next, using rustc 1.85.0, at commit 232e79c72f57
> ("rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0"):
>
> CLIPPY [M] drivers/gpu/drm/nova/nova.o
> warning: consider removing unnecessary double parentheses
> --> rust/doctests_kernel_generated.rs:4240:14
> |
> 4240 | pr_info!("The policy details are: {:?}\n", (policy.cpu(), policy.cur()));
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_parens
> = note: `-W clippy::double-parens` implied by `-W clippy::all`
> = help: to override `-W clippy::all` add `#[allow(clippy::double_parens)]`
>
> warning: 1 warning emitted
That is already fixed and in mainline: 487f9b3dc6e5 ("rust: cpufreq:
suppress clippy::double_parens in Policy doctest").
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 00/33] rust: bump minimum Rust and `bindgen` versions
From: John Hubbard @ 2026-04-06 18:51 UTC (permalink / raw)
To: Miguel Ojeda, Miguel Ojeda
Cc: Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, Simona Vetter,
Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <CANiq72mnGArtgAbe7xXZCYW1x7Zd5hozfnzoftaGy9rxoLO4ew@mail.gmail.com>
On 4/6/26 2:03 AM, Miguel Ojeda wrote:
> On Mon, Apr 6, 2026 at 1:53 AM Miguel Ojeda <ojeda@kernel.org> wrote:
...
> Applied series to `rust-next` -- thanks everyone!
>
> Let's see if we find any issue in -next.
>
Looks good from the perspective of this patchset. I am seeing
one remaining problem that we previously came up with a fix for,
so I expect that that fix is staged in another branch. But in
case it's not, here is the report:
On today's rust-next, using rustc 1.85.0, at commit 232e79c72f57
("rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0"):
CLIPPY [M] drivers/gpu/drm/nova/nova.o
warning: consider removing unnecessary double parentheses
--> rust/doctests_kernel_generated.rs:4240:14
|
4240 | pr_info!("The policy details are: {:?}\n", (policy.cpu(), policy.cur()));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_parens
= note: `-W clippy::double-parens` implied by `-W clippy::all`
= help: to override `-W clippy::all` add `#[allow(clippy::double_parens)]`
warning: 1 warning emitted
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v2 07/33] rust: allow globally `clippy::incompatible_msrv`
From: Tamir Duberstein @ 2026-04-06 15:30 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <CANiq72ne_JYPodnROckyNto10ZF0PqadRxSrng5-mZyqVovxFg@mail.gmail.com>
On Mon, Apr 6, 2026 at 10:38 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Mon, Apr 6, 2026 at 4:29 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > Could you add a reference to the upstream bug report [0] here?
>
> Of course, thanks for the tags!
You're welcome! Actually it seems the lint was already improved
upstream, starting with 1.90.0.
Link: https://github.com/rust-lang/rust-clippy/commit/c0dc3b61 [0]
^ permalink raw reply
* Re: [PATCH v2 0/2] ublk: fix infinite loop in ublk server teardown
From: Jens Axboe @ 2026-04-06 14:38 UTC (permalink / raw)
To: Ming Lei, zhang, the-essence-of-life, Caleb Sander Mateos,
Shuah Khan, Uday Shankar
Cc: linux-block, linux-kernel, linux-kselftest
In-Reply-To: <20260405-cancel-v2-0-02d711e643c2@purestorage.com>
On Sun, 05 Apr 2026 22:25:29 -0600, Uday Shankar wrote:
> Fix an infinite loop in ublk server teardown which can arise when a ublk
> server dies while recovering a device. Also add a test which
> demonstrates the problem and verifies the fix.
Applied, thanks!
[1/2] ublk: reset per-IO canceled flag on each fetch
commit: 0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b
[2/2] selftests: ublk: test that teardown after incomplete recovery completes
commit: 320f9b1c6a942a73c26be56742ee1da04f893a4f
Best regards,
--
Jens Axboe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox