* Re: improve the swap_activate interface
From: Steve French @ 2026-05-13 20:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Chris Li, Kairui Song, Christian Brauner,
Darrick J . Wong, Jens Axboe, David Sterba, Theodore Ts'o,
Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Namjae Jeon, Hyunchul Lee, Steve French, Paulo Alcantara,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, linux-xfs,
linux-fsdevel, linux-doc, linux-mm, linux-block, linux-btrfs,
linux-ext4, linux-f2fs-devel, linux-nfs, linux-cifs
In-Reply-To: <20260512053625.2950900-1-hch@lst.de>
I just tried this on 7.1-rc3 with the swap patches (full kernel build,
on Ubuntu 25,10) and boot failed with out of memory which I had never
seen before. Any idea how to workaround this with the swap patch
series, or is there a fix for this in the swap series already?
On Tue, May 12, 2026 at 12:41 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Hi all,
>
> Darrick recently posted iomap support for fuse-iomap, which was trivial
> but a bit ugly, which triggered me into looking how this could be done
> in a cleaner way. The result of that is this fairly big series that
> reworks how the MM code calls into the file system to activate swap
> files to make it much cleaner and easier to use.
>
> I've tested this with swap devices manually, and using the swap tests
> in xfstests on btrfs, ext3, ext4, f2fs and xfs to exercise the different
> implementation. Out of those all passed, but f2fs actually notruns all
> tests even in the baseline as it requires special preparation for
> swapfiles which never got wired up in xfstests.
>
> Diffstat:
> Documentation/filesystems/iomap/operations.rst | 3
> Documentation/filesystems/locking.rst | 35 +--
> Documentation/filesystems/vfs.rst | 40 ++--
> block/fops.c | 15 +
> fs/btrfs/btrfs_inode.h | 3
> fs/btrfs/file.c | 4
> fs/btrfs/inode.c | 72 -------
> fs/ext4/file.c | 6
> fs/ext4/inode.c | 11 -
> fs/f2fs/data.c | 50 -----
> fs/f2fs/f2fs.h | 2
> fs/f2fs/file.c | 4
> fs/iomap/swapfile.c | 165 +++---------------
> fs/nfs/direct.c | 1
> fs/nfs/file.c | 21 --
> fs/nfs/nfs4file.c | 3
> fs/ntfs/aops.c | 8
> fs/ntfs/file.c | 6
> fs/smb/client/cifsfs.c | 18 +
> fs/smb/client/cifsfs.h | 3
> fs/smb/client/file.c | 16 -
> fs/xfs/xfs_aops.c | 48 -----
> fs/xfs/xfs_file.c | 39 ++++
> fs/zonefs/file.c | 30 +--
> include/linux/fs.h | 11 -
> include/linux/iomap.h | 5
> include/linux/nfs_fs.h | 3
> include/linux/swap.h | 129 +-------------
> mm/page_io.c | 45 ----
> mm/swap.h | 92 ++++++++++
> mm/swapfile.c | 227 ++++++++++++++-----------
> 31 files changed, 471 insertions(+), 644 deletions(-)
>
--
Thanks,
Steve
^ permalink raw reply
* Re: fix block layer bounce buffering for block size > PAGE_SIZE v2
From: Jens Axboe @ 2026-05-13 19:56 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christian Brauner, Darrick J. Wong, Pankaj Raghav, linux-block,
linux-xfs, linux-fsdevel
In-Reply-To: <683792db-32fc-4765-9ba6-3712af01676c@kernel.dk>
On 5/13/26 11:15 AM, Jens Axboe wrote:
> On 5/6/26 11:01 PM, Christoph Hellwig wrote:
>> Hi all,
>>
>> this series has two fixes that make the new block layer bounce
>> buffering code work for the block size > PAGE_SIZE case.
>>
>> Changes since v1:
>> - update a commit log to better describe the applicability
>
> Can we get some Fixes tags on these, please?
Looked myself to not delay this any further, both marked with:
Fixes: 8dd5e7c75d7b ("block: add helpers to bounce buffer an iov_iter into bios")
--
Jens Axboe
^ permalink raw reply
* Re: fix block layer bounce buffering for block size > PAGE_SIZE v2
From: Jens Axboe @ 2026-05-13 19:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christian Brauner, Darrick J. Wong, Pankaj Raghav, linux-block,
linux-xfs, linux-fsdevel
In-Reply-To: <20260507050153.1298375-1-hch@lst.de>
On Thu, 07 May 2026 07:01:46 +0200, Christoph Hellwig wrote:
> this series has two fixes that make the new block layer bounce
> buffering code work for the block size > PAGE_SIZE case.
>
> Changes since v1:
> - update a commit log to better describe the applicability
>
> Diffstat:
> block/bio.c | 27 +++++++++++++++------------
> fs/iomap/direct-io.c | 2 +-
> include/linux/bio.h | 3 ++-
> 3 files changed, 18 insertions(+), 14 deletions(-)
>
> [...]
Applied, thanks!
[1/2] block: pass a minsize argument to bio_iov_iter_bounce
commit: 32d5019ed3b6ff4439cb075fb275f655c8a2059c
[2/2] block: align down bounces bios
commit: e7b8b3c5b2a65595d506ffedafac66f0a11fbdc2
Best regards,
--
Jens Axboe
^ permalink raw reply
* [PATCH V4 3/3] nvme-multipath: enable PCI P2PDMA for multipath devices
From: Chaitanya Kulkarni @ 2026-05-13 18:51 UTC (permalink / raw)
To: song, yukuai, linan122, kbusch, axboe, hch, sagi
Cc: linux-block, linux-raid, linux-nvme, kmodukuri,
Pranjal Shrivastava, Nitesh Shetty, Chaitanya Kulkarni
In-Reply-To: <20260513185153.95552-1-kch@nvidia.com>
From: Kiran Kumar Modukuri <kmodukuri@nvidia.com>
NVMe multipath does not expose BLK_FEAT_PCI_P2PDMA on the head disk
even when all underlying controllers support it.
Set BLK_FEAT_PCI_P2PDMA unconditionally in nvme_mpath_alloc_disk()
alongside the other features. nvme_update_ns_info_block() already
calls queue_limits_stack_bdev() to stack each path's limits onto the
head disk, which routes through blk_stack_limits(). The core now
clears BLK_FEAT_PCI_P2PDMA automatically if any path (e.g., FC) does
not support it, consistent with how BLK_FEAT_NOWAIT and BLK_FEAT_POLL
are handled.
Tested-by: Pranjal Shrivastava<praan@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com>
Signed-off-by: Kiran Kumar Modukuri <kmodukuri@nvidia.com>
Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
---
drivers/nvme/host/multipath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 263161cb8ac0..ff442bbf2937 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -730,7 +730,7 @@ int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl, struct nvme_ns_head *head)
blk_set_stacking_limits(&lim);
lim.dma_alignment = 3;
lim.features |= BLK_FEAT_IO_STAT | BLK_FEAT_NOWAIT |
- BLK_FEAT_POLL | BLK_FEAT_ATOMIC_WRITES;
+ BLK_FEAT_POLL | BLK_FEAT_ATOMIC_WRITES | BLK_FEAT_PCI_P2PDMA;
if (head->ids.csi == NVME_CSI_ZNS)
lim.features |= BLK_FEAT_ZONED;
--
2.39.5
^ permalink raw reply related
* [PATCH V4 2/3] md: propagate BLK_FEAT_PCI_P2PDMA from member devices to RAID device
From: Chaitanya Kulkarni @ 2026-05-13 18:51 UTC (permalink / raw)
To: song, yukuai, linan122, kbusch, axboe, hch, sagi
Cc: linux-block, linux-raid, linux-nvme, kmodukuri,
Pranjal Shrivastava, Xiao Ni, Chaitanya Kulkarni
In-Reply-To: <20260513185153.95552-1-kch@nvidia.com>
From: Kiran Kumar Modukuri <kmodukuri@nvidia.com>
MD RAID does not propagate BLK_FEAT_PCI_P2PDMA from member devices to
the RAID device, preventing peer-to-peer DMA through the RAID layer even
when all underlying devices support it.
Enable BLK_FEAT_PCI_P2PDMA unconditionally in raid0, raid1 and raid10
personalities during queue limits setup. blk_stack_limits() clears it
automatically if any member device lacks support, consistent with how
BLK_FEAT_NOWAIT and BLK_FEAT_POLL are handled in the block core.
Parity RAID personalities (raid4/5/6) are excluded because they require
CPU access to data pages for parity computation, which is incompatible
with P2P mappings.
Tested with RAID0/1/10 arrays containing multiple NVMe devices with
P2PDMA support, confirming that peer-to-peer transfers work correctly
through the RAID layer.
Tested-by: Pranjal Shrivastava<praan@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Kiran Kumar Modukuri <kmodukuri@nvidia.com>
Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
---
drivers/md/raid0.c | 1 +
drivers/md/raid1.c | 1 +
drivers/md/raid10.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index 5e38a51e349a..2cdaf7495d92 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -392,6 +392,7 @@ static int raid0_set_limits(struct mddev *mddev)
lim.io_opt = lim.io_min * mddev->raid_disks;
lim.chunk_sectors = mddev->chunk_sectors;
lim.features |= BLK_FEAT_ATOMIC_WRITES;
+ lim.features |= BLK_FEAT_PCI_P2PDMA;
err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
if (err)
return err;
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 64d970e2ef50..cc628a1be52c 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -3208,6 +3208,7 @@ static int raid1_set_limits(struct mddev *mddev)
lim.max_hw_wzeroes_unmap_sectors = 0;
lim.logical_block_size = mddev->logical_block_size;
lim.features |= BLK_FEAT_ATOMIC_WRITES;
+ lim.features |= BLK_FEAT_PCI_P2PDMA;
err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
if (err)
return err;
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 39085e7dd6d2..f905dc391b74 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3941,6 +3941,7 @@ static int raid10_set_queue_limits(struct mddev *mddev)
lim.chunk_sectors = mddev->chunk_sectors;
lim.io_opt = lim.io_min * raid10_nr_stripes(conf);
lim.features |= BLK_FEAT_ATOMIC_WRITES;
+ lim.features |= BLK_FEAT_PCI_P2PDMA;
err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);
if (err)
return err;
--
2.39.5
^ permalink raw reply related
* [PATCH V4 1/3] block: clear BLK_FEAT_PCI_P2PDMA in blk_stack_limits() for non-supporting devices
From: Chaitanya Kulkarni @ 2026-05-13 18:51 UTC (permalink / raw)
To: song, yukuai, linan122, kbusch, axboe, hch, sagi
Cc: linux-block, linux-raid, linux-nvme, kmodukuri,
Chaitanya Kulkarni, Pranjal Shrivastava, Nitesh Shetty
In-Reply-To: <20260513185153.95552-1-kch@nvidia.com>
BLK_FEAT_NOWAIT and BLK_FEAT_POLL are cleared in blk_stack_limits()
when an underlying device does not support them. Apply the same
treatment to BLK_FEAT_PCI_P2PDMA: stacking drivers set it
unconditionally and rely on the core to clear it whenever a
non-supporting member device is stacked.
Tested-by: Pranjal Shrivastava<praan@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com>
Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
---
block/blk-settings.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index 78c83817b9d3..8274631290db 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -795,6 +795,8 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
t->features &= ~BLK_FEAT_NOWAIT;
if (!(b->features & BLK_FEAT_POLL))
t->features &= ~BLK_FEAT_POLL;
+ if (!(b->features & BLK_FEAT_PCI_P2PDMA))
+ t->features &= ~BLK_FEAT_PCI_P2PDMA;
t->flags |= (b->flags & BLK_FLAG_MISALIGNED);
--
2.39.5
^ permalink raw reply related
* [PATCH V4 0/3] md/nvme: Enable PCI P2PDMA support for RAID0 and NVMe Multipath
From: Chaitanya Kulkarni @ 2026-05-13 18:51 UTC (permalink / raw)
To: song, yukuai, linan122, kbusch, axboe, hch, sagi
Cc: linux-block, linux-raid, linux-nvme, kmodukuri,
Chaitanya Kulkarni
Hi,
This patch series extends PCI peer-to-peer DMA (P2PDMA) support to enable
direct data transfers between PCIe devices through RAID and NVMe multipath
block layers.
Current Linux kernel P2PDMA infrastructure supports direct peer-to-peer
transfers, but this support is not propagated through certain storage
stacks like MD RAID and NVMe multipath. This adds two patches for
MD RAID 0/1/10 and NVMe to propogate P2PDMA support through the
storage stack.
All four test scenarios demonstrate that P2PDMA capabilities are correctly
propagated through both the MD RAID layer (patch 2/3) and NVMe multipath
layer (patch 3/3). Direct peer-to-peer transfers complete successfully with
full data integrity verification, confirming that:
1. RAID devices properly inherit P2PDMA capability from member devices
2. NVMe multipath devices correctly expose P2PDMA support
3. P2P memory buffers can be used for transfers involving both types
4. Data integrity is maintained across all transfer combinations
I've added blktest log as well at the end.
Repo:-
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git
Branch HEAD:-
commit 5d75bcab6af0916283c2675d831d39fe4d360b11 (origin/for-next)
Merge: feab7e5ae6ee 87d0740b7c4c
Author: Jens Axboe <axboe@kernel.dk>
Date: Wed May 13 07:55:56 2026 -0600
Merge branch 'block-7.1' into for-next
* block-7.1:
selftests: ublk: cap nthreads to kernel's actual nr_hw_queues
-ck
Changes from V3:-
1. Rebase on latest code and add review and tested by tags.
Changes from V2:-
1. Unconditionally set the BLK_FEAT_PCI_P2PDMA for md and nvme multipath.
(Christoph)
2. Add a prep patch to diable BLK_FEAT_PCI_P2PDMA in the blk_stack_limit().
(christoph)
Changes from V1:-
- Update patch 1 to explicitly support MD RAID 0/1/10.
- Fix signoff chain order for patch 2.
- Clear BLK_FEAT_PCI_P2PDMA in nvme_mpath_add_disk() when a newly
added path does not support it, to handle multipath across different
transports.
- Add nvme multipath test log for mixed transport TCP and PCIe.
Chaitanya Kulkarni (1):
block: clear BLK_FEAT_PCI_P2PDMA in blk_stack_limits() for
non-supporting devices
Kiran Kumar Modukuri (2):
md: propagate BLK_FEAT_PCI_P2PDMA from member devices to RAID device
nvme-multipath: enable PCI P2PDMA for multipath devices
block/blk-settings.c | 2 ++
drivers/md/raid0.c | 1 +
drivers/md/raid1.c | 1 +
drivers/md/raid10.c | 1 +
drivers/nvme/host/multipath.c | 2 +-
5 files changed, 6 insertions(+), 1 deletion(-)
++ for t in loop tcp
++ echo '################NVMET_TRTYPES=loop############'
################NVMET_TRTYPES=loop############
++ NVMET_TRTYPES=loop
++ ./check nvme
nvme/002 (tr=loop) (create many subsystems and test discovery) [passed]
runtime 33.808s ... 34.634s
nvme/003 (tr=loop) (test if we're sending keep-alives to a discovery controller) [passed]
runtime 10.222s ... 10.239s
nvme/004 (tr=loop) (test nvme and nvmet UUID NS descriptors) [passed]
runtime 0.683s ... 0.651s
nvme/005 (tr=loop) (reset local loopback target) [passed]
runtime 0.974s ... 1.001s
nvme/006 (tr=loop bd=device) (create an NVMeOF target) [passed]
runtime 0.088s ... 0.094s
nvme/006 (tr=loop bd=file) (create an NVMeOF target) [passed]
runtime 0.082s ... 0.087s
nvme/008 (tr=loop bd=device) (create an NVMeOF host) [passed]
runtime 0.652s ... 0.658s
nvme/008 (tr=loop bd=file) (create an NVMeOF host) [passed]
runtime 0.634s ... 0.658s
nvme/010 (tr=loop bd=device) (run data verification fio job) [passed]
runtime 9.426s ... 9.469s
nvme/010 (tr=loop bd=file) (run data verification fio job) [passed]
runtime 41.443s ... 43.716s
nvme/012 (tr=loop bd=device) (run mkfs and data verification fio) [passed]
runtime 47.971s ... 51.404s
nvme/012 (tr=loop bd=file) (run mkfs and data verification fio) [passed]
runtime 38.937s ... 38.971s
nvme/014 (tr=loop bd=device) (flush a command from host) [passed]
runtime 9.257s ... 9.208s
nvme/014 (tr=loop bd=file) (flush a command from host) [passed]
runtime 8.874s ... 8.863s
nvme/016 (tr=loop) (create/delete many NVMeOF block device-backed ns and test discovery) [passed]
runtime 20.101s ... 19.387s
nvme/017 (tr=loop) (create/delete many file-ns and test discovery) [passed]
runtime 22.534s ... 21.919s
nvme/018 (tr=loop) (unit test NVMe-oF out of range access on a file backend) [passed]
runtime 0.629s ... 0.653s
nvme/019 (tr=loop bd=device) (test NVMe DSM Discard command) [passed]
runtime 0.638s ... 0.657s
nvme/019 (tr=loop bd=file) (test NVMe DSM Discard command) [passed]
runtime 0.624s ... 0.611s
nvme/021 (tr=loop bd=device) (test NVMe list command) [passed]
runtime 0.633s ... 0.639s
nvme/021 (tr=loop bd=file) (test NVMe list command) [passed]
runtime 0.647s ... 0.632s
nvme/022 (tr=loop bd=device) (test NVMe reset command) [passed]
runtime 1.008s ... 1.011s
nvme/022 (tr=loop bd=file) (test NVMe reset command) [passed]
runtime 1.010s ... 1.006s
nvme/023 (tr=loop bd=device) (test NVMe smart-log command) [passed]
runtime 0.628s ... 0.623s
nvme/023 (tr=loop bd=file) (test NVMe smart-log command) [passed]
runtime 0.624s ... 0.627s
nvme/025 (tr=loop bd=device) (test NVMe effects-log) [passed]
runtime 0.647s ... 0.647s
nvme/025 (tr=loop bd=file) (test NVMe effects-log) [passed]
runtime 0.638s ... 0.636s
nvme/026 (tr=loop bd=device) (test NVMe ns-descs) [passed]
runtime 0.628s ... 0.647s
nvme/026 (tr=loop bd=file) (test NVMe ns-descs) [passed]
runtime 0.623s ... 0.637s
nvme/027 (tr=loop bd=device) (test NVMe ns-rescan command) [passed]
runtime 0.657s ... 0.658s
nvme/027 (tr=loop bd=file) (test NVMe ns-rescan command) [passed]
runtime 0.650s ... 0.641s
nvme/028 (tr=loop bd=device) (test NVMe list-subsys) [passed]
runtime 0.618s ... 0.642s
nvme/028 (tr=loop bd=file) (test NVMe list-subsys) [passed]
runtime 0.631s ... 0.627s
nvme/029 (tr=loop) (test userspace IO via nvme-cli read/write interface) [passed]
runtime 0.954s ... 0.952s
nvme/030 (tr=loop) (ensure the discovery generation counter is updated appropriately) [passed]
runtime 0.432s ... 0.437s
nvme/031 (tr=loop) (test deletion of NVMeOF controllers immediately after setup) [passed]
runtime 5.813s ... 5.999s
nvme/038 (tr=loop) (test deletion of NVMeOF subsystem without enabling) [passed]
runtime 0.035s ... 0.034s
nvme/040 (tr=loop) (test nvme fabrics controller reset/disconnect operation during I/O) [passed]
runtime 7.029s ... 7.022s
nvme/041 (tr=loop) (Create authenticated connections) [passed]
runtime 0.654s ... 0.684s
nvme/042 (tr=loop) (Test dhchap key types for authenticated connections) [passed]
runtime 3.866s ... 3.856s
nvme/043 (tr=loop) (Test hash and DH group variations for authenticated connections) [passed]
runtime 4.834s ... 4.886s
nvme/044 (tr=loop) (Test bi-directional authentication) [passed]
runtime 1.237s ... 1.328s
nvme/045 (tr=loop) (Test re-authentication) [passed]
runtime 1.570s ... 1.609s
nvme/047 (tr=loop) (test different queue types for fabric transports) [not run]
nvme_trtype=loop is not supported in this test
nvme/048 (tr=loop) (Test queue count changes on reconnect) [not run]
nvme_trtype=loop is not supported in this test
nvme/051 (tr=loop) (test nvmet concurrent ns enable/disable) [passed]
runtime 1.362s ... 1.407s
nvme/052 (tr=loop) (Test file-ns creation/deletion under one subsystem) [passed]
runtime 6.258s ... 6.282s
nvme/054 (tr=loop) (Test the NVMe reservation feature) [passed]
runtime 0.754s ... 0.769s
nvme/055 (tr=loop) (Test nvme write to a loop target ns just after ns is disabled) [not run]
kernel option DEBUG_ATOMIC_SLEEP has not been enabled
nvme/056 (tr=loop) (enable zero copy offload and run rw traffic) [not run]
Remote target required but NVME_TARGET_CONTROL is not set
nvme_trtype=loop is not supported in this test
kernel option ULP_DDP has not been enabled
module nvme_tcp does not have parameter ddp_offload
KERNELSRC not set
Kernel sources do not have tools/net/ynl/cli.py
NVME_IFACE not set
nvme/057 (tr=loop) (test nvme fabrics controller ANA failover during I/O) [passed]
runtime 27.227s ... 27.146s
nvme/058 (tr=loop) (test rapid namespace remapping) [passed]
runtime 4.646s ... 4.746s
nvme/060 (tr=loop) (test nvme fabrics target reset) [not run]
nvme_trtype=loop is not supported in this test
nvme/061 (tr=loop) (test fabric target teardown and setup during I/O) [not run]
nvme_trtype=loop is not supported in this test
nvme/062 (tr=loop) (Create TLS-encrypted connections) [not run]
nvme_trtype=loop is not supported in this test
nvme/063 (tr=loop) (Create authenticated TCP connections with secure concatenation) [not run]
nvme_trtype=loop is not supported in this test
nvme/065 (tr=loop) (test unmap write zeroes sysfs interface with nvmet devices) [passed]
runtime 2.310s ... 2.270s
++ for t in loop tcp
++ echo '################NVMET_TRTYPES=tcp############'
################NVMET_TRTYPES=tcp############
++ NVMET_TRTYPES=tcp
++ ./check nvme
nvme/002 (tr=tcp) (create many subsystems and test discovery) [not run]
nvme_trtype=tcp is not supported in this test
nvme/003 (tr=tcp) (test if we're sending keep-alives to a discovery controller) [passed]
runtime 10.279s ... 10.271s
nvme/004 (tr=tcp) (test nvme and nvmet UUID NS descriptors) [passed]
runtime 0.350s ... 0.404s
nvme/005 (tr=tcp) (reset local loopback target) [passed]
runtime 0.434s ... 0.466s
nvme/006 (tr=tcp bd=device) (create an NVMeOF target) [passed]
runtime 0.097s ... 0.098s
nvme/006 (tr=tcp bd=file) (create an NVMeOF target) [passed]
runtime 0.089s ... 0.094s
nvme/008 (tr=tcp bd=device) (create an NVMeOF host) [passed]
runtime 0.348s ... 0.361s
nvme/008 (tr=tcp bd=file) (create an NVMeOF host) [passed]
runtime 0.370s ... 0.395s
nvme/010 (tr=tcp bd=device) (run data verification fio job) [passed]
runtime 76.430s ... 78.689s
nvme/010 (tr=tcp bd=file) (run data verification fio job) [passed]
runtime 120.407s ... 116.963s
nvme/012 (tr=tcp bd=device) (run mkfs and data verification fio) [passed]
runtime 85.918s ... 84.974s
nvme/012 (tr=tcp bd=file) (run mkfs and data verification fio) [passed]
runtime 120.326s ... 120.123s
nvme/014 (tr=tcp bd=device) (flush a command from host) [passed]
runtime 9.603s ... 9.522s
nvme/014 (tr=tcp bd=file) (flush a command from host) [passed]
runtime 9.319s ... 9.297s
nvme/016 (tr=tcp) (create/delete many NVMeOF block device-backed ns and test discovery) [not run]
nvme_trtype=tcp is not supported in this test
nvme/017 (tr=tcp) (create/delete many file-ns and test discovery) [not run]
nvme_trtype=tcp is not supported in this test
nvme/018 (tr=tcp) (unit test NVMe-oF out of range access on a file backend) [passed]
runtime 0.334s ... 0.384s
nvme/019 (tr=tcp bd=device) (test NVMe DSM Discard command) [passed]
runtime 0.342s ... 0.377s
nvme/019 (tr=tcp bd=file) (test NVMe DSM Discard command) [passed]
runtime 0.334s ... 0.368s
nvme/021 (tr=tcp bd=device) (test NVMe list command) [passed]
runtime 0.357s ... 0.400s
nvme/021 (tr=tcp bd=file) (test NVMe list command) [passed]
runtime 0.356s ... 0.397s
nvme/022 (tr=tcp bd=device) (test NVMe reset command) [passed]
runtime 0.469s ... 0.504s
nvme/022 (tr=tcp bd=file) (test NVMe reset command) [passed]
runtime 0.441s ... 0.512s
nvme/023 (tr=tcp bd=device) (test NVMe smart-log command) [passed]
runtime 0.348s ... 0.387s
nvme/023 (tr=tcp bd=file) (test NVMe smart-log command) [passed]
runtime 0.330s ... 0.372s
nvme/025 (tr=tcp bd=device) (test NVMe effects-log) [passed]
runtime 0.351s ... 0.384s
nvme/025 (tr=tcp bd=file) (test NVMe effects-log) [passed]
runtime 0.362s ... 0.377s
nvme/026 (tr=tcp bd=device) (test NVMe ns-descs) [passed]
runtime 0.343s ... 0.359s
nvme/026 (tr=tcp bd=file) (test NVMe ns-descs) [passed]
runtime 0.317s ... 0.361s
nvme/027 (tr=tcp bd=device) (test NVMe ns-rescan command) [passed]
runtime 0.375s ... 0.412s
nvme/027 (tr=tcp bd=file) (test NVMe ns-rescan command) [passed]
runtime 0.388s ... 0.392s
nvme/028 (tr=tcp bd=device) (test NVMe list-subsys) [passed]
runtime 0.355s ... 0.362s
nvme/028 (tr=tcp bd=file) (test NVMe list-subsys) [passed]
runtime 0.342s ... 0.371s
nvme/029 (tr=tcp) (test userspace IO via nvme-cli read/write interface) [passed]
runtime 0.698s ... 0.742s
nvme/030 (tr=tcp) (ensure the discovery generation counter is updated appropriately) [passed]
runtime 0.402s ... 0.416s
nvme/031 (tr=tcp) (test deletion of NVMeOF controllers immediately after setup) [passed]
runtime 3.068s ... 3.161s
nvme/038 (tr=tcp) (test deletion of NVMeOF subsystem without enabling) [passed]
runtime 0.041s ... 0.042s
nvme/040 (tr=tcp) (test nvme fabrics controller reset/disconnect operation during I/O) [passed]
runtime 6.442s ... 6.478s
nvme/041 (tr=tcp) (Create authenticated connections) [passed]
runtime 0.408s ... 0.407s
nvme/042 (tr=tcp) (Test dhchap key types for authenticated connections) [passed]
runtime 1.803s ... 1.879s
nvme/043 (tr=tcp) (Test hash and DH group variations for authenticated connections) [passed]
runtime 2.484s ... 2.515s
nvme/044 (tr=tcp) (Test bi-directional authentication) [passed]
runtime 0.732s ... 0.732s
nvme/045 (tr=tcp) (Test re-authentication) [passed]
runtime 1.322s ... 1.310s
nvme/047 (tr=tcp) (test different queue types for fabric transports) [passed]
runtime 1.863s ... 1.879s
nvme/048 (tr=tcp) (Test queue count changes on reconnect) [passed]
runtime 6.525s ... 5.523s
nvme/051 (tr=tcp) (test nvmet concurrent ns enable/disable) [passed]
runtime 1.336s ... 1.361s
nvme/052 (tr=tcp) (Test file-ns creation/deletion under one subsystem) [not run]
nvme_trtype=tcp is not supported in this test
nvme/054 (tr=tcp) (Test the NVMe reservation feature) [passed]
runtime 0.493s ... 0.491s
nvme/055 (tr=tcp) (Test nvme write to a loop target ns just after ns is disabled) [not run]
nvme_trtype=tcp is not supported in this test
kernel option DEBUG_ATOMIC_SLEEP has not been enabled
nvme/056 (tr=tcp) (enable zero copy offload and run rw traffic) [not run]
Remote target required but NVME_TARGET_CONTROL is not set
kernel option ULP_DDP has not been enabled
module nvme_tcp does not have parameter ddp_offload
KERNELSRC not set
Kernel sources do not have tools/net/ynl/cli.py
NVME_IFACE not set
nvme/057 (tr=tcp) (test nvme fabrics controller ANA failover during I/O) [passed]
runtime 25.906s ... 25.963s
nvme/058 (tr=tcp) (test rapid namespace remapping) [passed]
runtime 3.145s ... 3.126s
nvme/060 (tr=tcp) (test nvme fabrics target reset) [passed]
runtime 20.395s ... 19.399s
nvme/061 (tr=tcp) (test fabric target teardown and setup during I/O) [passed]
runtime 8.549s ... 8.617s
nvme/062 (tr=tcp) (Create TLS-encrypted connections) [failed]
runtime 1.608s ... 5.200s
--- tests/nvme/062.out 2026-01-28 12:04:48.888356244 -0800
+++ /mnt/sda/blktests/results/nodev_tr_tcp/nvme/062.out.bad 2026-05-13 11:33:33.891029529 -0700
@@ -2,9 +2,13 @@
Test unencrypted connection w/ tls not required
disconnected 1 controller(s)
Test encrypted connection w/ tls not required
-disconnected 1 controller(s)
+FAIL: nvme connect return error code
+WARNING: connection is not encrypted
+disconnected 0 controller(s)
...
(Run 'diff -u tests/nvme/062.out /mnt/sda/blktests/results/nodev_tr_tcp/nvme/062.out.bad' to see the entire diff)
nvme/063 (tr=tcp) (Create authenticated TCP connections with secure concatenation) [passed]
runtime 1.838s ... 2.011s
nvme/065 (tr=tcp) (test unmap write zeroes sysfs interface with nvmet devices) [passed]
runtime 1.749s ... 1.758s
++ ./manage-rdma-nvme.sh --cleanup
====== RDMA NVMe Setup ======
RDMA Type: siw
Interface: auto-detect
[INFO] Checking prerequisites...
[INFO] Prerequisites check passed
[INFO] Loading RDMA module: siw
[INFO] Module siw loaded successfully
[INFO] Creating RDMA links...
[INFO] Creating RDMA link: ens5_siw
[INFO] Created RDMA link: ens5_siw -> ens5
++ ./manage-rdma-nvme.sh --status
====== RDMA Configuration Status ======
====== RDMA Network Configuration Status ======
Loaded Modules:
siw 217088
nvmet 258048
RDMA Links:
link ens5_siw/1 state ACTIVE physical_state LINK_UP netdev ens5
Network Interfaces (RDMA-capable):
Interface: ens5
IPv4: 192.168.0.46
IPv6: fe80::5054:98ff:fe76:5440%ens5
blktests Configuration:
Transport Address: 192.168.0.46:4420
Transport Type: rdma
Command: NVMET_TRTYPES=rdma ./check nvme/
NVMe RDMA Controllers:
None
=================================================
++ echo '################NVMET_TRTYPES=rdma############'
################NVMET_TRTYPES=rdma############
++ NVMET_TRTYPES=rdma
++ ./check nvme
nvme/002 (tr=rdma) (create many subsystems and test discovery) [not run]
nvme_trtype=rdma is not supported in this test
nvme/003 (tr=rdma) (test if we're sending keep-alives to a discovery controller) [passed]
runtime 10.315s ... 10.293s
nvme/004 (tr=rdma) (test nvme and nvmet UUID NS descriptors) [passed]
runtime 0.695s ... 0.750s
nvme/005 (tr=rdma) (reset local loopback target) [passed]
runtime 0.974s ... 1.046s
nvme/006 (tr=rdma bd=device) (create an NVMeOF target) [passed]
runtime 0.136s ... 0.149s
nvme/006 (tr=rdma bd=file) (create an NVMeOF target) [passed]
runtime 0.127s ... 0.140s
nvme/008 (tr=rdma bd=device) (create an NVMeOF host) [passed]
runtime 0.684s ... 0.685s
nvme/008 (tr=rdma bd=file) (create an NVMeOF host) [passed]
runtime 0.672s ... 0.729s
nvme/010 (tr=rdma bd=device) (run data verification fio job) [passed]
runtime 35.255s ... 35.280s
nvme/010 (tr=rdma bd=file) (run data verification fio job) [passed]
runtime 68.570s ... 66.260s
nvme/012 (tr=rdma bd=device) (run mkfs and data verification fio) [passed]
runtime 47.482s ... 42.242s
nvme/012 (tr=rdma bd=file) (run mkfs and data verification fio) [passed]
runtime 61.407s ... 62.511s
nvme/014 (tr=rdma bd=device) (flush a command from host) [passed]
runtime 9.855s ... 9.321s
nvme/014 (tr=rdma bd=file) (flush a command from host) [passed]
runtime 9.919s ... 9.175s
nvme/016 (tr=rdma) (create/delete many NVMeOF block device-backed ns and test discovery) [not run]
nvme_trtype=rdma is not supported in this test
nvme/017 (tr=rdma) (create/delete many file-ns and test discovery) [not run]
nvme_trtype=rdma is not supported in this test
nvme/018 (tr=rdma) (unit test NVMe-oF out of range access on a file backend) [passed]
runtime 0.654s ... 0.737s
nvme/019 (tr=rdma bd=device) (test NVMe DSM Discard command) [passed]
runtime 0.664s ... 0.738s
nvme/019 (tr=rdma bd=file) (test NVMe DSM Discard command) [passed]
runtime 0.649s ... 0.730s
nvme/021 (tr=rdma bd=device) (test NVMe list command) [passed]
runtime 0.676s ... 0.729s
nvme/021 (tr=rdma bd=file) (test NVMe list command) [passed]
runtime 0.673s ... 0.720s
nvme/022 (tr=rdma bd=device) (test NVMe reset command) [passed]
runtime 1.021s ... 1.066s
nvme/022 (tr=rdma bd=file) (test NVMe reset command) [passed]
runtime 1.015s ... 1.055s
nvme/023 (tr=rdma bd=device) (test NVMe smart-log command) [passed]
runtime 0.633s ... 0.718s
nvme/023 (tr=rdma bd=file) (test NVMe smart-log command) [passed]
runtime 0.656s ... 0.673s
nvme/025 (tr=rdma bd=device) (test NVMe effects-log) [passed]
runtime 0.706s ... 0.715s
nvme/025 (tr=rdma bd=file) (test NVMe effects-log) [passed]
runtime 0.688s ... 0.733s
nvme/026 (tr=rdma bd=device) (test NVMe ns-descs) [passed]
runtime 0.686s ... 0.690s
nvme/026 (tr=rdma bd=file) (test NVMe ns-descs) [passed]
runtime 0.669s ... 0.684s
nvme/027 (tr=rdma bd=device) (test NVMe ns-rescan command) [passed]
runtime 0.703s ... 0.731s
nvme/027 (tr=rdma bd=file) (test NVMe ns-rescan command) [passed]
runtime 0.707s ... 0.772s
nvme/028 (tr=rdma bd=device) (test NVMe list-subsys) [passed]
runtime 0.680s ... 0.712s
nvme/028 (tr=rdma bd=file) (test NVMe list-subsys) [passed]
runtime 0.670s ... 0.709s
nvme/029 (tr=rdma) (test userspace IO via nvme-cli read/write interface) [passed]
runtime 1.077s ... 1.087s
nvme/030 (tr=rdma) (ensure the discovery generation counter is updated appropriately) [passed]
runtime 0.511s ... 0.560s
nvme/031 (tr=rdma) (test deletion of NVMeOF controllers immediately after setup) [passed]
runtime 5.869s ... 6.106s
nvme/038 (tr=rdma) (test deletion of NVMeOF subsystem without enabling) [passed]
runtime 0.084s ... 0.085s
nvme/040 (tr=rdma) (test nvme fabrics controller reset/disconnect operation during I/O) [passed]
runtime 7.024s ... 6.994s
nvme/041 (tr=rdma) (Create authenticated connections) [passed]
runtime 0.718s ... 0.769s
nvme/042 (tr=rdma) (Test dhchap key types for authenticated connections) [passed]
runtime 3.759s ... 3.968s
nvme/043 (tr=rdma) (Test hash and DH group variations for authenticated connections) [passed]
runtime 4.487s ... 4.880s
nvme/044 (tr=rdma) (Test bi-directional authentication) [passed]
runtime 1.279s ... 1.393s
nvme/045 (tr=rdma) (Test re-authentication) [passed]
runtime 1.837s ... 1.892s
nvme/047 (tr=rdma) (test different queue types for fabric transports) [passed]
runtime 2.642s ... 2.700s
nvme/048 (tr=rdma) (Test queue count changes on reconnect) [passed]
runtime 5.810s ... 6.860s
nvme/051 (tr=rdma) (test nvmet concurrent ns enable/disable) [passed]
runtime 1.479s ... 1.408s
nvme/052 (tr=rdma) (Test file-ns creation/deletion under one subsystem) [not run]
nvme_trtype=rdma is not supported in this test
nvme/054 (tr=rdma) (Test the NVMe reservation feature) [passed]
runtime 0.799s ... 0.854s
nvme/055 (tr=rdma) (Test nvme write to a loop target ns just after ns is disabled) [not run]
nvme_trtype=rdma is not supported in this test
kernel option DEBUG_ATOMIC_SLEEP has not been enabled
nvme/056 (tr=rdma) (enable zero copy offload and run rw traffic) [not run]
Remote target required but NVME_TARGET_CONTROL is not set
nvme_trtype=rdma is not supported in this test
kernel option ULP_DDP has not been enabled
module nvme_tcp does not have parameter ddp_offload
KERNELSRC not set
Kernel sources do not have tools/net/ynl/cli.py
NVME_IFACE not set
nvme/057 (tr=rdma) (test nvme fabrics controller ANA failover during I/O) [passed]
runtime 26.984s ... 27.074s
nvme/058 (tr=rdma) (test rapid namespace remapping) [passed]
runtime 4.444s ... 4.553s
nvme/060 (tr=rdma) (test nvme fabrics target reset) [passed]
runtime 20.696s ... 22.308s
nvme/061 (tr=rdma) (test fabric target teardown and setup during I/O) [passed]
runtime 15.375s ... 15.348s
nvme/062 (tr=rdma) (Create TLS-encrypted connections) [not run]
nvme_trtype=rdma is not supported in this test
nvme/063 (tr=rdma) (Create authenticated TCP connections with secure concatenation) [not run]
nvme_trtype=rdma is not supported in this test
nvme/065 (tr=rdma) (test unmap write zeroes sysfs interface with nvmet devices) [passed]
runtime 2.369s ... 2.466s
++ ./manage-rdma-nvme.sh --cleanup
====== RDMA NVMe Cleanup ======
[INFO] Disconnecting NVMe RDMA controllers...
[INFO] No NVMe RDMA controllers to disconnect
[INFO] Removing RDMA links...
[INFO] No RDMA links to remove
[INFO] Unloading NVMe RDMA modules...
[INFO] Unloading module: nvme_rdma
[INFO] Module nvme_rdma unloaded
[INFO] Unloading module: nvmet_rdma
[INFO] Module nvmet_rdma unloaded
[INFO] Unloading module: nvmet
--
2.39.5
^ permalink raw reply
* [PATCH v4] bio-integrity-fs: pass data iter to bio_integrity_verify()
From: Caleb Sander Mateos @ 2026-05-13 18:29 UTC (permalink / raw)
To: Jens Axboe
Cc: Caleb Sander Mateos, Anuj Gupta, Christoph Hellwig, linux-block,
linux-kernel
bio_integrity_verify() expects the passed struct bvec_iter to be an
iterator over bio data, not integrity. So construct a separate data
bvec_iter without the bio_integrity_bytes() conversion and pass it to
bio_integrity_verify() instead of bip_iter.
Fixes: 0bde8a12b554 ("block: add fs_bio_integrity helpers")
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
v4: split from series changing ref tag seed units
v3: https://lore.kernel.org/linux-block/20260417015732.2692434-3-csander@purestorage.com/
block/bio-integrity-fs.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/block/bio-integrity-fs.c b/block/bio-integrity-fs.c
index acb1e5f270d2..0daa42d9ead7 100644
--- a/block/bio-integrity-fs.c
+++ b/block/bio-integrity-fs.c
@@ -53,21 +53,25 @@ EXPORT_SYMBOL_GPL(fs_bio_integrity_generate);
int fs_bio_integrity_verify(struct bio *bio, sector_t sector, unsigned int size)
{
struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk);
struct bio_integrity_payload *bip = bio_integrity(bio);
+ struct bvec_iter data_iter = {
+ .bi_sector = sector,
+ .bi_size = size,
+ };
/*
* Reinitialize bip->bip_iter.
*
* This is for use in the submitter after the driver is done with the
* bio. Requires the submitter to remember the sector and the size.
*/
memset(&bip->bip_iter, 0, sizeof(bip->bip_iter));
bip->bip_iter.bi_sector = sector;
bip->bip_iter.bi_size = bio_integrity_bytes(bi, size >> SECTOR_SHIFT);
- return blk_status_to_errno(bio_integrity_verify(bio, &bip->bip_iter));
+ return blk_status_to_errno(bio_integrity_verify(bio, &data_iter));
}
static int __init fs_bio_integrity_init(void)
{
fs_bio_integrity_cache = kmem_cache_create("fs_bio_integrity",
--
2.54.0
^ permalink raw reply related
* Re: [PATCH blktests 2/3] common/rc: add _echo() function to trace sysfs attribute writes
From: Bart Van Assche @ 2026-05-13 17:17 UTC (permalink / raw)
To: Shin'ichiro Kawasaki, linux-block; +Cc: Daniel Wagner, John Meneghini
In-Reply-To: <20260513112326.584256-3-shinichiro.kawasaki@wdc.com>
On 5/13/26 4:23 AM, Shin'ichiro Kawasaki wrote:
> +# Echo a value to a file. This wrapper is used to trace sysfs attribute writes
Echo -> Write
file -> sysfs/debugfs/configfs attribute
sysfs -> sysfs/debugfs/configfs
> +# when the --cmd-trace option is enabled.
> +_echo() {
> + echo "$1" > "$2"
> +}
If this is only used to write into sysfs/debugfs/configfs, there are
probably better names for this function than _echo, e.g. _set_attr(),
_write_attr() or _write_sys_attr().
Should "echo" or "echo -n" be used in the above shell function?
Thanks,
Bart.
^ permalink raw reply
* Re: fix block layer bounce buffering for block size > PAGE_SIZE v2
From: Jens Axboe @ 2026-05-13 17:15 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christian Brauner, Darrick J. Wong, Pankaj Raghav, linux-block,
linux-xfs, linux-fsdevel
In-Reply-To: <20260507050153.1298375-1-hch@lst.de>
On 5/6/26 11:01 PM, Christoph Hellwig wrote:
> Hi all,
>
> this series has two fixes that make the new block layer bounce
> buffering code work for the block size > PAGE_SIZE case.
>
> Changes since v1:
> - update a commit log to better describe the applicability
Can we get some Fixes tags on these, please?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH blktests 1/3] check: add --cmd-trace option
From: Bart Van Assche @ 2026-05-13 17:08 UTC (permalink / raw)
To: Shin'ichiro Kawasaki, linux-block; +Cc: Daniel Wagner, John Meneghini
In-Reply-To: <20260513112326.584256-2-shinichiro.kawasaki@wdc.com>
On 5/13/26 4:23 AM, Shin'ichiro Kawasaki wrote:
> diff --git a/check b/check
> index c166fae..a68049b 100755
> --- a/check
> +++ b/check
> @@ -458,7 +458,17 @@ _call_test() {
>
> TIMEFORMAT="%Rs"
> pushd . >/dev/null || return
> + if ((CMD_TRACE)); then
> + exec 8>"${seqres}.cmdtrace"
> + export BASH_XTRACEFD=8
> + set -x
> + fi
Hmm ... my experience is that set -x breaks most tests.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH blktests 2/3] common/rc: add _echo() function to trace sysfs attribute writes
From: Bart Van Assche @ 2026-05-13 17:07 UTC (permalink / raw)
To: Daniel Wagner, Shin'ichiro Kawasaki
Cc: linux-block, Daniel Wagner, John Meneghini
In-Reply-To: <a1668df1-a93a-442a-ae95-e015bcbeec17@flourine.local>
On 5/13/26 7:05 AM, Daniel Wagner wrote:
> On Wed, May 13, 2026 at 08:23:25PM +0900, Shin'ichiro Kawasaki wrote:
>> +# Echo a value to a file. This wrapper is used to trace sysfs attribute writes
>> +# when the --cmd-trace option is enabled.
>> +_echo() {
>> + echo "$1" > "$2"
>> +}
>
> Stupid question, can't we override the echo function, something like this:
>
> echo() {
> builtin echo "$@"
> builtin echo "$@" >> "/tmp/debug_log.txt"
> }
How can this work since the sysfs/debugfs/configfs attribute is not an
argument of the echo command?
Thanks,
Bart.
^ permalink raw reply
* [PATCH] drbd: fix false positive resync throttling in drbd_rs_c_min_rate_throttle
From: Ionut Nechita (Wind River) @ 2026-05-13 16:39 UTC (permalink / raw)
To: drbd-dev, linux-block, linux-kernel
Cc: Philipp Reisner, Lars Ellenberg, Christoph Boehmwalder,
Jens Axboe, Chris Friesen, Ionut Nechita
In-Reply-To: <20260513163905.562722-1-ionut.nechita@windriver.com>
From: Ionut Nechita <ionut.nechita@windriver.com>
drbd_rs_c_min_rate_throttle() is intended to slow down resync when
genuine application I/O is competing for the backing device. It used
to detect "application I/O" by comparing the total sector count from
the backing device (part_stat_read_accum) against the resync sector
counter (rs_sect_ev), and throttling when the resync speed exceeds
c-min-rate.
That curr_events heuristic produces false positives:
1) On the receiver path, rs_sect_ev is incremented *after* the throttle
check. The current resync I/O is already reflected in part_stat
counters but not yet in rs_sect_ev, creating a persistent positive
delta that looks like application I/O.
2) The per-cpu part_stat counters and the atomic rs_sect_ev are not
read under any common lock, so transient skew between them can
push the delta above 64 sectors even when no application I/O is
present.
When the false positive fires, the function compares the resync speed
against c-min-rate (default 35840 KB/s ~ 35 MB/s). On modern
hardware capable of 300+ MB/s resync the condition is almost always
true, so the caller sleeps 100 ms (HZ/10) per resync request or stops
issuing new requests, capping throughput at roughly c-min-rate.
This was observed in production on a Distributed Cloud controller
where drbd-dc-vault (100 GB) resynced at ~30 MB/s instead of the
expected ~360 MB/s. Setting c-min-rate above the actual resync speed
(e.g. 350 MB/s) or disabling the feature (c-min-rate 0) restored full
throughput, confirming false-positive throttling as root cause.
Switch the gate to ap_bio_cnt. inc_ap_bio() is called for every
application bio at the top of drbd_make_request(), before any
activity-log handling, and dec_ap_bio() runs on completion. That
makes ap_bio_cnt the authoritative "application I/O in flight"
signal, independent of part_stat update timing, per-cpu skew, and
activity-log fastpath outcomes.
Backport of the drbd 9.x fix to the in-tree drbd 8.4 driver.
Suggested-by: Ionut Nechita <ionut.nechita@windriver.com>
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
[inechita: backport to drbd 8.4 - ap_bio_cnt is scalar, not array]
Signed-off-by: Ionut Nechita <ionut.nechita@windriver.com>
---
drivers/block/drbd/drbd_int.h | 2 -
drivers/block/drbd/drbd_main.c | 1 -
drivers/block/drbd/drbd_receiver.c | 62 ++++++++++++++++--------------
drivers/block/drbd/drbd_worker.c | 3 --
4 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index e21492981f7dd..9ed613775e9e2 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -883,8 +883,6 @@ struct drbd_device {
atomic_t rs_sect_in; /* for incoming resync data rate, SyncTarget */
atomic_t rs_sect_ev; /* for submitted resync data rate, both */
int rs_last_sect_ev; /* counter to compare with */
- int rs_last_events; /* counter of read or write "events" (unit sectors)
- * on the lower level device when we last looked. */
int c_sync_rate; /* current resync rate after syncer throttle magic */
struct fifo_buffer *rs_plan_s; /* correction values of resync planer (RCU, connection->conn_update) */
int rs_in_flight; /* resync sectors in flight (to proxy, in proxy and from proxy) */
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 8c5a7bcfa82b2..0371fec05befa 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2019,7 +2019,6 @@ void drbd_device_cleanup(struct drbd_device *device)
device->rs_start =
device->rs_total =
device->rs_failed = 0;
- device->rs_last_events = 0;
device->rs_last_sect_ev = 0;
for (i = 0; i < DRBD_SYNC_MARKS; i++) {
device->rs_mark_left[i] = 0;
diff --git a/drivers/block/drbd/drbd_receiver.c b/drivers/block/drbd/drbd_receiver.c
index ac18d36b0ea84..da59e919e20e6 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -2757,50 +2757,56 @@ bool drbd_rs_should_slow_down(struct drbd_peer_device *peer_device, sector_t sec
return throttle;
}
+/*
+ * Throttle resync when application I/O is in flight on the backing
+ * device and the resync is running faster than c-min-rate.
+ *
+ * The previous heuristic compared the backing device's part_stat
+ * sectors counter against our own rs_sect_ev counter (similar to
+ * MD RAID is_mddev_idle()) and fired on a delta > 64 sectors. That
+ * comparison is racy: rs_sect_ev is bumped at submission while
+ * part_stat is updated on bio completion (and is per-cpu), and the
+ * receiver path bumps rs_sect_ev *after* the throttle check. On
+ * fast hardware the transient skew routinely exceeds 64 sectors
+ * even with no application I/O, capping resync throughput at
+ * c-min-rate.
+ *
+ * ap_bio_cnt is incremented unconditionally for every application
+ * request in drbd_make_request(), so it is the authoritative
+ * "is application I/O in flight" signal.
+ */
bool drbd_rs_c_min_rate_throttle(struct drbd_device *device)
{
- struct gendisk *disk = device->ldev->backing_bdev->bd_disk;
unsigned long db, dt, dbdt;
unsigned int c_min_rate;
- int curr_events;
+ unsigned long rs_left;
+ int i;
rcu_read_lock();
c_min_rate = rcu_dereference(device->ldev->disk_conf)->c_min_rate;
rcu_read_unlock();
- /* feature disabled? */
if (c_min_rate == 0)
return false;
- curr_events = (int)part_stat_read_accum(disk->part0, sectors) -
- atomic_read(&device->rs_sect_ev);
-
- if (atomic_read(&device->ap_actlog_cnt)
- || curr_events - device->rs_last_events > 64) {
- unsigned long rs_left;
- int i;
-
- device->rs_last_events = curr_events;
+ if (!atomic_read(&device->ap_bio_cnt))
+ return false;
- /* sync speed average over the last 2*DRBD_SYNC_MARK_STEP,
- * approx. */
- i = (device->rs_last_mark + DRBD_SYNC_MARKS-1) % DRBD_SYNC_MARKS;
+ /* sync speed average over the last 2*DRBD_SYNC_MARK_STEP, approx. */
+ i = (device->rs_last_mark + DRBD_SYNC_MARKS - 1) % DRBD_SYNC_MARKS;
- if (device->state.conn == C_VERIFY_S || device->state.conn == C_VERIFY_T)
- rs_left = device->ov_left;
- else
- rs_left = drbd_bm_total_weight(device) - device->rs_failed;
+ if (device->state.conn == C_VERIFY_S || device->state.conn == C_VERIFY_T)
+ rs_left = device->ov_left;
+ else
+ rs_left = drbd_bm_total_weight(device) - device->rs_failed;
- dt = ((long)jiffies - (long)device->rs_mark_time[i]) / HZ;
- if (!dt)
- dt++;
- db = device->rs_mark_left[i] - rs_left;
- dbdt = Bit2KB(db/dt);
+ dt = ((long)jiffies - (long)device->rs_mark_time[i]) / HZ;
+ if (!dt)
+ dt++;
+ db = device->rs_mark_left[i] - rs_left;
+ dbdt = Bit2KB(db / dt);
- if (dbdt > c_min_rate)
- return true;
- }
- return false;
+ return dbdt > c_min_rate;
}
static int receive_DataRequest(struct drbd_connection *connection, struct packet_info *pi)
diff --git a/drivers/block/drbd/drbd_worker.c b/drivers/block/drbd/drbd_worker.c
index 4352a50fbb3f8..632281afffad4 100644
--- a/drivers/block/drbd/drbd_worker.c
+++ b/drivers/block/drbd/drbd_worker.c
@@ -1676,14 +1676,11 @@ void drbd_resync_after_changed(struct drbd_device *device)
void drbd_rs_controller_reset(struct drbd_peer_device *peer_device)
{
struct drbd_device *device = peer_device->device;
- struct gendisk *disk = device->ldev->backing_bdev->bd_disk;
struct fifo_buffer *plan;
atomic_set(&device->rs_sect_in, 0);
atomic_set(&device->rs_sect_ev, 0);
device->rs_in_flight = 0;
- device->rs_last_events =
- (int)part_stat_read_accum(disk->part0, sectors);
/* Updating the RCU protected object in place is necessary since
this function gets called from atomic context.
--
2.43.0
^ permalink raw reply related
* [PATCH 0/1] drbd: fix false positive resync throttling (in-tree 8.4)
From: Ionut Nechita (Wind River) @ 2026-05-13 16:39 UTC (permalink / raw)
To: drbd-dev, linux-block, linux-kernel
Cc: Philipp Reisner, Lars Ellenberg, Christoph Boehmwalder,
Jens Axboe, Chris Friesen, Ionut Nechita
From: Ionut Nechita <ionut.nechita@windriver.com>
Hi Philipp, Lars, Christoph,
This is the in-tree drbd 8.4 backport of the ap_bio_cnt throttle fix
that was previously sent against drbd 9.3.2.
The drbd 9.x version (using ap_bio_cnt[] array) was Suggested-by me
and Signed-off-by Philipp. This patch adapts it to the in-tree 8.4
driver where ap_bio_cnt is a scalar atomic_t rather than a per-direction
array.
The fix replaces the racy part_stat/curr_events heuristic in
drbd_rs_c_min_rate_throttle() with a direct check of ap_bio_cnt,
eliminating false-positive throttling that caps resync at c-min-rate
(~35 MB/s) on high-speed links.
Tested on a Distributed Cloud controller (StarlingX, kernel 6.12-rt)
with 10G/100G Mellanox ConnectX-6:
- Before: drbd-dc-vault (100 GB) resync at ~30 MB/s
- After: drbd-dc-vault resync at ~340-350 MB/s (full link speed)
Based on: linux-6.12.y (6.12.87)
Ionut Nechita (1):
drbd: fix false positive resync throttling in
drbd_rs_c_min_rate_throttle
drivers/block/drbd/drbd_int.h | 2 -
drivers/block/drbd/drbd_main.c | 1 -
drivers/block/drbd/drbd_receiver.c | 62 ++++++++++++++++--------------
drivers/block/drbd/drbd_worker.c | 3 --
4 files changed, 34 insertions(+), 34 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH] block: bio-integrity: fix memory leak in bio_integrity_map_user()
From: Dmitry Antipov @ 2026-05-13 15:43 UTC (permalink / raw)
To: Caleb Sander Mateos
Cc: Jens Axboe, Weidong Zhu, Chao Shi, Sungwoo Kim, Dave Tian,
Keith Busch, Christoph Hellwig, linux-block, lvc-project
In-Reply-To: <CADUfDZo972nK0iE79ogjob5_VN2-i-7L5XypDbdW0bupNfTo+g@mail.gmail.com>
On Wed, 2026-05-13 at 07:32 -0700, Caleb Sander Mateos wrote:
> I preferred your previous patch changing iov_iter_extract_pages() to
> free the page array on error.
Me too.
> Even though bio_integrity_map_user() is the only current caller that
> requests iov_iter_extract_pages() allocate a page array, others could
> be added in the future and forget to do this freeing.
It was in the past. Again, the whole thing was started from 6.12, see
https://lore.kernel.org/stable/20260505094529.406783-1-dmantipov@yandex.ru
(the commit message is somewhat messy BTW), and I'm definitely interested
in supporting that longterm too.
> Is there a reason you decided to modify bio_integrity_map_user() instead?
Sure. Such an ad-hoc quick fixes are much more likely to be integrated
within a reasonable time and effort from the maintainer. OTOH better wait for
Jens' answer before doing anything else.
Dmitry
^ permalink raw reply
* Re: [PATCH 08/12] swap,iomap: simplify iomap_swapfile_iter
From: Darrick J. Wong @ 2026-05-13 14:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Chris Li, Kairui Song, Christian Brauner,
Jens Axboe, David Sterba, Theodore Ts'o, Jaegeuk Kim, Chao Yu,
Trond Myklebust, Anna Schumaker, Namjae Jeon, Hyunchul Lee,
Steve French, Paulo Alcantara, Carlos Maiolino, Damien Le Moal,
Naohiro Aota, linux-xfs, linux-fsdevel, linux-doc, linux-mm,
linux-block, linux-btrfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs
In-Reply-To: <20260513065608.GA2250@lst.de>
On Wed, May 13, 2026 at 08:56:08AM +0200, Christoph Hellwig wrote:
> On Tue, May 12, 2026 at 10:02:04AM -0700, Darrick J. Wong wrote:
> > OH. Now I remember why -- it's to handle contiguous mixed mappings
> > better.
> >
> > Let's say that you have a 1k fsblock filesystem and 4k base pages. You
> > fallocate an 8G swap file and then mkswap it. The first mapping is a 1k
> > written mapping at offset 0 for the swap header, followed by an 8388607k
> > unwritten mapping at offset 3k.
> >
> > The PAGE_SIZE rounding code in iomap_swapfile_add_extent will round the
> > end of that first mapping down to zero and ignore it. The second
> > mapping will be treated as if it were a 8388604k mapping starting at
> > offset 4096. Now the page counts are wrong and the swapon fails.
>
> Do we care about this use case? I guess you did as you implemented
> his, but still?
We do, because mkswap -F uses fallocate nowadays:
$ mkswap -s 4194304 -F a
Setting up swapspace version 1, size = 4 MiB (4190208 bytes)
no label, UUID=bc9746bf-e200-4944-927c-80d83872f1cb
$ filefrag -v a
Filesystem type is: 58465342
File size of a is 4194304 (1024 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 0: 411383552.. 411383552: 1:
1: 1.. 1023: 411383553.. 411384575: 1023: last,unwritten,eof
a: 1 extent found
> > A more generic solution to this would be to change add_swap_extent to
> > take sector_t addr and length values and use them to construct a bitmap
> > representing contiguous physical space on the bdev, accounting of course
> > for PAGE_SIZE alignment. Except for the swap header page, every other
> > contiguously set page-aligned region in the bitmap gets added to the
> > swap extent map.
>
> You don't even need a bitmap, just do basically the same checks as
> the iomap code when moving to a new swap extent after moving to use
> the sector_t. And it really should anyway, as the current abuse of
> sector_t to store a disk offset in PAGE_SIZE units is pretty gross.
Oh, I meant this to handle the particularly gross case where the fsblock
size is smaller than a base page, but there are a very large number of
file mappings that point to a physically contiguous extent but are not
in logical order:
{.offset=0, .length=1k, .addr=7},
{.offset=1, .length=1k, .addr=6},
{.offset=2, .length=1k, .addr=5},
{.offset=3, .length=1k, .addr=4},
{.offset=4, .length=1k, .addr=3},
{.offset=5, .length=1k, .addr=2},
{.offset=6, .length=1k, .addr=1},
{.offset=7, .length=1k, .addr=0},
That's two pages of swapfile, but with the current layout accumulation
code we "cannot" find either.
--D
^ permalink raw reply
* Re: [PATCH] configfs: rust: add an API for adding default groups from C
From: Andreas Hindborg @ 2026-05-13 14:39 UTC (permalink / raw)
To: Alice Ryhl
Cc: Boqun Feng, Jens Axboe, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross,
Danilo Krummrich, Breno Leitao, linux-kernel, linux-block,
rust-for-linux
In-Reply-To: <aZLXSPk2uO-R0e6b@google.com>
Alice Ryhl <aliceryhl@google.com> writes:
> On Sun, Feb 15, 2026 at 09:33:47PM +0100, Andreas Hindborg wrote:
>> Some C subsystems provide a feature to add configfs default groups to the
>> configfs hierarchy of other drivers or subsystems. Rust abstractions for
>> these subsystems will want a way to add these default groups via the
>> configfs Rust API. So add infrastructure to make this possible.
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>> drivers/block/rnull/configfs.rs | 1 +
>> rust/helpers/configfs.c | 16 ++++++++++++++++
>> rust/helpers/helpers.c | 1 +
>> rust/kernel/configfs.rs | 33 ++++++++++++++++++++++++++++++++-
>> samples/rust/rust_configfs.rs | 8 +++++++-
>> 5 files changed, 57 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/rnull/configfs.rs b/drivers/block/rnull/configfs.rs
>> index 6713a6d92391d..ea38b27a9011c 100644
>> --- a/drivers/block/rnull/configfs.rs
>> +++ b/drivers/block/rnull/configfs.rs
>> @@ -78,6 +78,7 @@ fn make_group(
>> name: name.try_into()?,
>> }),
>> }),
>> + core::iter::empty(),
>> ))
>> }
>> }
>> diff --git a/rust/helpers/configfs.c b/rust/helpers/configfs.c
>> new file mode 100644
>> index 0000000000000..7cec8ffcb093d
>> --- /dev/null
>> +++ b/rust/helpers/configfs.c
>> @@ -0,0 +1,16 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <linux/configfs.h>
>> +
>> +__rust_helper void
>> +rust_helper_configfs_add_default_group(struct config_group *new_group,
>> + struct config_group *group)
>> +{
>> + configfs_add_default_group(new_group, group);
>> +}
>> +
>> +__rust_helper void
>> +__rust_helper_configfs_remove_default_groups(struct config_group *group)
>
> Only the annotation has the two __ prefix, not the symbol name.
Hmm, odd that the bindings generate correct anyway.
>
>> +#[pinned_drop]
>> +impl<Data> PinnedDrop for Group<Data> {
>> + fn drop(self: Pin<&mut Self>) {
>> + // SAFETY: We have exclusive access to `self` and we know the default groups are alive
>> + // because we reference them through `self.default_groups`.
>> + unsafe { bindings::configfs_remove_default_groups(self.group.get()) };
>
> Why isn't this here already?
What do you mean. The drop of default groups is not there already,
because it was not previously possible to add default groups. So there
would be nothing to drop.
>
>> + }
>> }
>>
>> impl<Data> Group<Data> {
>> @@ -259,7 +269,13 @@ pub fn new(
>> name: CString,
>> item_type: &'static ItemType<Group<Data>, Data>,
>> data: impl PinInit<Data, Error>,
>> + default_groups: impl IntoIterator<Item = Arc<dyn CDefaultGroup>>,
>
> Honestly, I'd just take a KVec here.
I was trying to be fancy. Is it not more flexible to take an iterator?
What are the pros/cons?
>
>> ) -> impl PinInit<Self, Error> {
>> + let mut dg = KVec::new();
>> + for group in default_groups {
>> + dg.push(group, GFP_KERNEL).unwrap();
>> + }
>> +
>> try_pin_init!(Self {
>> group <- pin_init::init_zeroed().chain(|v: &mut Opaque<bindings::config_group>| {
>> let place = v.get();
>> @@ -268,13 +284,28 @@ pub fn new(
>> unsafe {
>> bindings::config_group_init_type_name(place, name.cast(), item_type.as_ptr())
>> };
>> +
>> + for default_group in &dg {
>> + // SAFETY: We keep the default groups alive until `Self` is dropped.
>> + unsafe { bindings::configfs_add_default_group(default_group.group_ptr(), place) }
>> + }
>
> Do these not need to be removed in drop?
Yes, I added the drop logic above. It is the hunk you asked why is it not
already here?
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH] block: bio-integrity: fix memory leak in bio_integrity_map_user()
From: Caleb Sander Mateos @ 2026-05-13 14:32 UTC (permalink / raw)
To: Dmitry Antipov
Cc: Jens Axboe, Weidong Zhu, Chao Shi, Sungwoo Kim, Dave Tian,
Keith Busch, Christoph Hellwig, linux-block, lvc-project
In-Reply-To: <20260513070515.528861-1-dmantipov@yandex.ru>
On Wed, May 13, 2026 at 12:05 AM Dmitry Antipov <dmantipov@yandex.ru> wrote:
>
> Since 'iov_iter_extract_pages()' may allocate new array of pages
> even when it returns non-zero error value, matching cleanup with
> 'vfree()' should be performed on all return paths afterwards. So
> adjust 'bio_integrity_map_user()' to ensure that both 'pages' and
> 'bvec' arrays are always freed on return.
I preferred your previous patch changing iov_iter_extract_pages() to
free the page array on error. (I left some minor comments on the code
change, but the general approach seems good.) Even though
bio_integrity_map_user() is the only current caller that requests
iov_iter_extract_pages() allocate a page array, others could be added
in the future and forget to do this freeing. And it's conventional for
functions to release any allocated resources on failure. Is there a
reason you decided to modify bio_integrity_map_user() instead?
Best,
Caleb
>
> Fixes: 8582792cf23b ("block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user()")
> Fixes: 492c5d455969 ("block: bio-integrity: directly map user buffers")
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> block/bio-integrity.c | 21 ++++++---------------
> 1 file changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> index e796de1a749e..53fb04adb09b 100644
> --- a/block/bio-integrity.c
> +++ b/block/bio-integrity.c
> @@ -400,7 +400,7 @@ int bio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
> ret = iov_iter_extract_pages(iter, &pages, bytes, nr_vecs,
> extraction_flags, &offset);
> if (unlikely(ret < 0))
> - goto free_bvec;
> + goto out_free;
>
> /*
> * Handle partial pinning. This can happen when pin_user_pages_fast()
> @@ -414,16 +414,12 @@ int bio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
> for (i = 0; i < npinned; i++)
> unpin_user_page(pages[i]);
> }
> - if (pages != stack_pages)
> - kvfree(pages);
> ret = -EFAULT;
> - goto free_bvec;
> + goto out_free;
> }
>
> nr_bvecs = bvec_from_pages(bvec, pages, nr_vecs, bytes, offset,
> &is_p2p);
> - if (pages != stack_pages)
> - kvfree(pages);
> if (nr_bvecs > queue_max_integrity_segments(q))
> copy = true;
> if (is_p2p)
> @@ -434,15 +430,10 @@ int bio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
> else
> ret = bio_integrity_init_user(bio, bvec, nr_bvecs, bytes);
> if (ret)
> - goto release_pages;
> - if (bvec != stack_vec)
> - kfree(bvec);
> -
> - return 0;
> -
> -release_pages:
> - bio_integrity_unpin_bvec(bvec, nr_bvecs);
> -free_bvec:
> + bio_integrity_unpin_bvec(bvec, nr_bvecs);
> +out_free:
> + if (pages != stack_pages)
> + kvfree(pages);
> if (bvec != stack_vec)
> kfree(bvec);
> return ret;
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH blktests 2/3] common/rc: add _echo() function to trace sysfs attribute writes
From: Daniel Wagner @ 2026-05-13 14:05 UTC (permalink / raw)
To: Shin'ichiro Kawasaki; +Cc: linux-block, Daniel Wagner, John Meneghini
In-Reply-To: <20260513112326.584256-3-shinichiro.kawasaki@wdc.com>
On Wed, May 13, 2026 at 08:23:25PM +0900, Shin'ichiro Kawasaki wrote:
> +# Echo a value to a file. This wrapper is used to trace sysfs attribute writes
> +# when the --cmd-trace option is enabled.
> +_echo() {
> + echo "$1" > "$2"
> +}
Stupid question, can't we override the echo function, something like this:
echo() {
builtin echo "$@"
builtin echo "$@" >> "/tmp/debug_log.txt"
}
^ permalink raw reply
* [PATCH] Re:[PATCH v3] zram: fix use-after-free in zram_writeback_endio
From: wang wei @ 2026-05-13 14:02 UTC (permalink / raw)
To: richardycc
Cc: akpm, axboe, bgeffon, linux-block, linux-kernel, linux-mm,
liumartin, minchan, senozhatsky, stable, wang wei
In-Reply-To: <20260512074918.2606208-1-richardycc@google.com>
>@@ -847,7 +849,7 @@ static void release_wb_ctl(struct zram_wb_ctl *wb_ctl)
> release_wb_req(req);
> }
>
>- kfree(wb_ctl);
>+ kfree_rcu(wb_ctl, rcu);
> }
Do we need to add a 'rcu_assign_pointer(wb_ctl, NULL);' before 'kfree_rcu(wb_ctl, rcu)'?
Signed-off-by: wang wei <a929244872@163.com>
--
2.25.1
^ permalink raw reply
* Re: [PATCH V2] selftests: ublk: cap nthreads to kernel's actual nr_hw_queues
From: Jens Axboe @ 2026-05-13 13:56 UTC (permalink / raw)
To: linux-block, Ming Lei; +Cc: Caleb Sander Mateos, Uday Shankar
In-Reply-To: <20260513101941.1373998-1-tom.leiming@gmail.com>
On Wed, 13 May 2026 18:19:40 +0800, Ming Lei wrote:
> dev->nthreads is derived from the user-requested queue count before the
> ADD command, but the kernel may reduce nr_hw_queues (capped to
> nr_cpu_ids). When the VM has fewer CPUs than requested queues, the
> daemon creates more handler threads than there are kernel queues.
>
> In non-batch mode, the extra threads access uninitialized queues
> (q_depth=0), submit zero io_uring SQEs, and block forever in
> io_cqring_wait. In batch mode, the extra threads cause similar hangs
> during device removal.
>
> [...]
Applied, thanks!
[1/1] selftests: ublk: cap nthreads to kernel's actual nr_hw_queues
commit: 87d0740b7c4cc847be1b6f307ab6d8547cb1a726
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] block: fix handling of dead zone write plugs
From: Jens Axboe @ 2026-05-13 13:56 UTC (permalink / raw)
To: linux-block, Damien Le Moal; +Cc: Christoph Hellwig, Shin'ichiro Kawasaki
In-Reply-To: <20260513111129.108809-1-dlemoal@kernel.org>
On Wed, 13 May 2026 20:11:29 +0900, Damien Le Moal wrote:
> Shin'ichiro reported hard to reproduce unaligned write errors with zoned
> block devices. Under normal operation conditions (e.g. running XFS on an
> SMR disk), these errors are nearly impossible to trigger. But using a
> "slow" kernel with many debug options enables and some specific use cases
> (e.g. fio zbd test case 46), the errors can be reproduced fairly easily.
>
> The unaligned write errors come from mishandling a valid reference
> counting pattern of zone write plugs. Such pattern triggers for instance
> if a process A writes a zone (not necessarilly to the full state), another
> process B immediately resets the zone and immediately following the
> completion of the zone reset, starts issuing writes to the zone. With such
> pattern, in some cases, the zone write plugs worker thread of the device
> may still be holding a reference to the zone write plug of the zone taken
> when process A was writing to the zone. The following zone reset from
> process B marks the zone as dead but does not remove the zone write plug
> from the device hash table as a reference to the plug still exist. Once
> process B starts issuing new writes, the zone write plug is seen as dead
> and the writes from process B are immediately failed, despite this write
> pattern being perfectly legal.
>
> [...]
Applied, thanks!
[1/1] block: fix handling of dead zone write plugs
commit: 836efd35c472d89c838d7b17ef339ddb3286ffc5
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] drbd: clean up UAPI headers
From: Jens Axboe @ 2026-05-13 13:54 UTC (permalink / raw)
To: Christoph Böhmwalder
Cc: drbd-dev, linux-kernel, Lars Ellenberg, Philipp Reisner,
linux-block, kernel test robot
In-Reply-To: <20260513110343.3170338-1-christoph.boehmwalder@linbit.com>
On Wed, 13 May 2026 13:03:42 +0200, Christoph Böhmwalder wrote:
> Commit b1798910fc7f ("drbd: move UAPI headers to include/uapi/linux/")
> broke compilation on targets without a hosted libc:
>
> ./usr/include/linux/drbd.h:18:10: fatal error: sys/types.h: No such
> file or directory
>
> The underlying issue is that there were some constructs left over in
> those headers that don't belong in uapi.
>
> [...]
Applied, thanks!
[1/1] drbd: clean up UAPI headers
commit: d5607f1fafd7eb72ed693b6a033d96221e870edd
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v4 02/12] block/bdev: Annotate the blk_holder_ops callback functions
From: Nathan Chancellor @ 2026-05-13 13:36 UTC (permalink / raw)
To: Marco Elver
Cc: Bart Van Assche, Peter Zijlstra, Jens Axboe, linux-block,
Christoph Hellwig
In-Reply-To: <CANpmjNM_rCMzbz88SSmmQU2h0+OvjoyN=VapkBc4OEwF=fRcvA@mail.gmail.com>
On Wed, May 13, 2026 at 08:54:57AM +0200, Marco Elver wrote:
> On Tue, 12 May 2026 at 21:28, Bart Van Assche <bvanassche@acm.org> wrote:
> >
> > On 5/11/26 3:19 PM, Marco Elver wrote:
> > > On Mon, 11 May 2026 at 18:31, Bart Van Assche <bvanassche@acm.org> wrote:
> > >>
> > >> The four callback functions in blk_holder_ops all release the
> > >> bd_holder_lock. Annotate these functions accordingly.
> > >>
> > >> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> > >
> > > Because of this change we'll need clang 23, or you add:
> > >
> > > CONTEXT_ANALYSIS := $(call clang-min-version, 230000)
> > >
> > > .. although anything else that includes blkdev.h that has
> > > CONTEXT_ANALYSIS := y, but is compiled with clang 22 will break.
> > >
> > > Would have been good to wait for clang 23 to be released (August this
> > > year) - although if we consider the next merge window + final release
> > > of Linux 7.2, it might get reasonably close to August.
> >
> > Hi Marco,
> >
> > How about detecting whether or not Clang supports context annotations
> > for function pointers, e.g. as follows?
> >
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 2937c4d308ae..61e592205179 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -32,6 +32,9 @@ config CLANG_VERSION
> > default $(cc-version) if CC_IS_CLANG
> > default 0
> >
> > +config CC_CONTEXT_ANNOTATIONS_ON_FUNCTION_POINTERS
> > + def_bool $(success, echo 'struct __attribute__((capability("m"))) m {
> > }; struct a { void (*fp)(struct m* m)
> > __attribute__((release_capability(m))); };' | $(CC) -x c - -c -Wall
> > -Wextra -Werror -o /dev/null)
> > +
> > config AS_IS_GNU
> > def_bool $(success,test "$(as-name)" = GNU)
>
> That works, but invokes the compiler every time to sync the config,
> adding a tiny bit of latency; I think we already have too many of
> those, and in this case a version check is sufficient. Clang 23 has
> not yet been released, and anyone using the current dev version ought
> to use the latest one.
Yeah, any time we do a prerelease check, we assume that people are
upgrading their prerelease compilers with regular cadence, otherwise
they are doing something wrong :)
> Maybe Nathan can keep me honest about the real overhead of this. :-)
While doing a dynamic check is more expensive than a version check, I
would not worry much about that overhead if the check is worthwhile or
valuable. In this case, I tend to agree with you that it would just be
better to bump the minimum version of Clang required for context
analysis because of the improvements (other than the function pointer
support) that you have landed in main since release/22.x. While I am
always sad to see support for older compilers dropped, I don't think
clang-22 is widespread enough for that to really matter. On the other
hand, I do worry that if we do not have a wide enough window of
supported compilers for developers / maintainers to use, we won't be
able to uncover potential problems to address in the compiler (I feel
like getting __counted_by deployed was particular painful for this
reason), if that makes sense.
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v3 02/10] iov_iter: add iterator type for dmabuf maps
From: David Laight @ 2026-05-13 13:29 UTC (permalink / raw)
To: Pavel Begunkov
Cc: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg,
Alexander Viro, Christian Brauner, Andrew Morton, Sumit Semwal,
Christian König, linux-block, linux-kernel, linux-nvme,
linux-fsdevel, io-uring, linux-media, dri-devel, linaro-mm-sig,
Nitesh Shetty, Kanchan Joshi, Anuj Gupta, Tushar Gohad,
William Power, Phil Cayton, Jason Gunthorpe
In-Reply-To: <20260513110557.705bdeed@pumpkin>
On Wed, 13 May 2026 11:05:57 +0100
David Laight <david.laight.linux@gmail.com> wrote:
...
> > @@ -575,7 +575,8 @@ void iov_iter_advance(struct iov_iter *i, size_t size)
> > {
> > if (unlikely(i->count < size))
> > size = i->count;
> > - if (likely(iter_is_ubuf(i)) || unlikely(iov_iter_is_xarray(i))) {
> > + if (likely(iter_is_ubuf(i)) || unlikely(iov_iter_is_xarray(i)) ||
> > + unlikely(iov_iter_is_dmabuf_map(i))) {
>
>
> Doesn't the extra check add more code to all the non-ubuf cases?
> This could be fixed by either making iter_type a bitmask (with one bit set)
> or writing an iter_is_one_of(i, ITER_xxx, ITER_yyy) define that uses
> '(1 << i->iter_type) & ((1 << ITER_xxx) | ...)'
This seems to DTRT:
#define _ITER_IS_ONE_OF(iter, t1, t2, t3, t4, t5, t6, t7, t8, ...) \
((1u << (iter)->iter_type) & ((1u << ITER_##t1) | (1u << ITER_##t2) | \
(1u << ITER_##t3) | (1u << ITER_##t4) | (1u << ITER_##t5) | \
(1u << ITER_##t6) | (1u << ITER_##t7) | (1u << ITER_##t8)))
#define ITER_IS_ONE_OF(iter, t, ...) \
_ITER_IS_ONE_OF(iter, t, ## __VA_ARGS__, t, t, t, t, t, t, t)
int foo(void *);
int f(struct iov_iter *i)
{
return ITER_IS_ONE_OF(i, UBUF, KVEC) ? foo(i) : 0;
}
See https://godbolt.org/z/sMz93zah1
Pasting ITER_ on the front ensures the values are constants of the right type.
OTOH it makes it harder to search for uses of each type.
You could paste _ITER_ on the front, elsewhere define _ITER_ITER_UVEC
to be ITER_UVEC (etc), and require the caller use the full name.
-- David
^ 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