From: Chaitanya Kulkarni To: CC: , , Chaitanya Kulkarni Subject: [PATCH] block: fix get_max_segment_size() warning Date: Mon, 8 Jul 2024 21:54:32 -0700 Message-ID: <20240709045432.8688-1-kch@nvidia.com> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.linux-block:93935 Newsgroups: org.kernel.vger.linux-block Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Correct the parameter name in the comment of get_max_segment_size() to fix following warning:- block/blk-merge.c:220: warning: Function parameter or struct member 'len' not described in 'get_max_segment_size' block/blk-merge.c:220: warning: Excess function parameter 'max_len' description in 'get_max_segment_size' Signed-off-by: Chaitanya Kulkarni --- block/blk-merge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-merge.c b/block/blk-merge.c index 94502261e24a..668b784bc246 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -210,7 +210,7 @@ static inline unsigned get_max_io_size(struct bio *bio, * get_max_segment_size() - maximum number of bytes to add as a single segment * @lim: Request queue limits. * @paddr: address of the range to add - * @max_len: maximum length available to add at @paddr + * @len: maximum length available to add at @paddr * * Returns the maximum number of bytes of the range starting at @paddr that can * be added to a single segment. -- 2.40.0 . X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Yi Zhang Date: Tue, 9 Jul 2024 14:21:12 +0800 Message-ID: Subject: [bug report] WARNING at block/blk-merge.c:607 __blk_rq_map_sg+0xf0/0x110 and BUG at drivers/scsi/scsi_lib.c:1160! on linux-block/for-next To: Jens Axboe Cc: linux-block , Shinichiro Kawasaki Content-Type: text/plain; charset="UTF-8" Xref: photonic.trudheim.com org.kernel.vger.linux-block:93946 Newsgroups: org.kernel.vger.linux-block Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hello blktests block/032 triggered the below issue on commit [1] during CKI tests, please help check it, thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git @ for-next Commit Hash: 7f8851d381f71952787db6a1a71bef4d286f3df0 https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:1364149314 [ 416.295727] run blktests block/032 at 2024-07-08 06:21:48 [ 416.359441] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 416.368491] scsi host48: scsi_debug: version 0191 [20210520] [ 416.368491] dev_size_mb=300, opts=0x0, submit_queues=1, statistics=0 [ 416.380875] scsi 48:0:0:0: Direct-Access Linux scsi_debug 0191 PQ: 0 ANSI: 7 [ 416.389131] scsi 48:0:0:0: Power-on or device reset occurred [ 416.398529] sd 48:0:0:0: Attached scsi generic sg1 type 0 [ 416.404965] sd 48:0:0:0: [sdb] 614400 512-byte logical blocks: (315 MB/300 MiB) [ 416.413275] sd 48:0:0:0: [sdb] Write Protect is off [ 416.420165] sd 48:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 416.434793] sd 48:0:0:0: [sdb] permanent stream count = 5 [ 416.443204] sd 48:0:0:0: [sdb] Preferred minimum I/O size 512 bytes [ 416.449460] sd 48:0:0:0: [sdb] Optimal transfer size 524288 bytes [ 416.492664] sd 48:0:0:0: [sdb] Attached SCSI disk [ 416.772750] ------------[ cut here ]------------ [ 416.777361] WARNING: CPU: 99 PID: 17829 at block/blk-merge.c:607 __blk_rq_map_sg+0xf0/0x110 [ 416.785705] Modules linked in: scsi_debug pktcdvd rfkill sunrpc vfat fat acpi_ipmi ipmi_ssif arm_spe_pmu igb ipmi_devintf arm_cmn arm_dmc620_pmu ipmi_msghandler acpiphp_ampere_altra arm_dsu_pmu cppc_cpufreq acpi_tad loop fuse nfnetlink zram xfs crct10dif_ce polyval_ce polyval_generic ghash_ce sbsa_gwdt ast onboard_usb_dev i2c_algo_bit xgene_hwmon [last unloaded: null_blk] [ 416.818633] CPU: 99 PID: 17829 Comm: mkfs.xfs Not tainted 6.10.0-rc6 #1 [ 416.825234] Hardware name: GIGABYTE R152-P31-00/MP32-AR1-00, BIOS F31n (SCP: 2.10.20220810) 09/30/2022 [ 416.834526] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 416.841475] pc : __blk_rq_map_sg+0xf0/0x110 [ 416.845646] lr : __blk_rq_map_sg+0x34/0x110 [ 416.849817] sp : ffff8000874eb2e0 [ 416.853118] x29: ffff8000874eb2e0 x28: ffff07ffee061a00 x27: ffff07ffedb16c00 [ 416.860241] x26: ffff07ffec440000 x25: 0000000000000008 x24: 0000000000000000 [ 416.867364] x23: ffff080087b260d8 x22: ffff07ffec440000 x21: 0000000000000002 [ 416.874488] x20: ffff8000874eb330 x19: ffff080087b25f00 x18: ffffb5fd2a5a1538 [ 416.881610] x17: 0000000000000400 x16: fffffe1fbeead042 x15: 0000000000000c00 [ 416.888733] x14: 0000000000000fff x13: ffffb5fd2a5a1000 x12: 0000000000000004 [ 416.895855] x11: 0000000000000000 x10: 0000000000000c00 x9 : 0000000000001000 [ 416.902978] x8 : ffff080087b2617c x7 : 0000000000000c00 x6 : 0000000000000000 [ 416.910100] x5 : 0000000000001000 x4 : 0000000000000001 x3 : ffff8000874eb330 [ 416.917223] x2 : 0000000000002302 x1 : 0000000000000002 x0 : 0000000000000004 [ 416.924345] Call trace: [ 416.926779] __blk_rq_map_sg+0xf0/0x110 [ 416.930603] scsi_alloc_sgtables+0x90/0x350 [ 416.934775] sd_setup_read_write_cmnd+0x98/0x660 [ 416.939381] sd_init_command+0x84/0x4f0 [ 416.943205] scsi_prepare_cmd+0x134/0x1d0 [ 416.947202] scsi_queue_rq+0x3d0/0x4a0 [ 416.950938] blk_mq_dispatch_rq_list+0x118/0x500 [ 416.955543] __blk_mq_do_dispatch_sched+0x330/0x350 [ 416.960408] __blk_mq_sched_dispatch_requests+0x170/0x1c0 [ 416.965795] blk_mq_sched_dispatch_requests+0x34/0x80 [ 416.970834] blk_mq_run_hw_queue+0x1ac/0x1d0 [ 416.975091] blk_mq_dispatch_plug_list+0x164/0x2c8 [ 416.979869] blk_mq_flush_plug_list.part.0+0x44/0x178 [ 416.984907] blk_mq_flush_plug_list+0x24/0x40 [ 416.989251] __blk_flush_plug+0x110/0x180 [ 416.993248] __submit_bio+0x1b0/0x230 [ 416.996897] submit_bio_noacct_nocheck+0x144/0x268 [ 417.001675] submit_bio_noacct+0x144/0x5e8 [ 417.005758] submit_bio+0xc0/0x250 [ 417.009147] submit_bio_wait+0x5c/0xb0 [ 417.012884] __blkdev_direct_IO_simple+0x10c/0x238 [ 417.017662] blkdev_direct_IO+0x144/0x188 [ 417.021659] blkdev_write_iter+0x1d0/0x2a8 [ 417.025743] vfs_write+0x24c/0x380 [ 417.029134] ksys_pwrite64+0x84/0xd0 [ 417.032696] __arm64_sys_pwrite64+0x28/0x40 [ 417.036866] invoke_syscall+0x74/0x100 [ 417.040604] el0_svc_common.constprop.0+0xc8/0xf0 [ 417.045294] do_el0_svc+0x24/0x38 [ 417.048596] el0_svc+0x3c/0x158 [ 417.051726] el0t_64_sync_handler+0x120/0x138 [ 417.056071] el0t_64_sync+0x194/0x198 [ 417.059720] ---[ end trace 0000000000000000 ]--- [ 417.064350] ------------[ cut here ]------------ [ 417.068954] kernel BUG at drivers/scsi/scsi_lib.c:1160! [ 417.074167] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 417.080248] Modules linked in: scsi_debug pktcdvd rfkill sunrpc vfat fat acpi_ipmi ipmi_ssif arm_spe_pmu igb ipmi_devintf arm_cmn arm_dmc620_pmu ipmi_msghandler acpiphp_ampere_altra arm_dsu_pmu cppc_cpufreq acpi_tad loop fuse nfnetlink zram xfs crct10dif_ce polyval_ce polyval_generic ghash_ce sbsa_gwdt ast onboard_usb_dev i2c_algo_bit xgene_hwmon [last unloaded: null_blk] [ 417.113166] CPU: 99 PID: 17829 Comm: mkfs.xfs Tainted: G W 6.10.0-rc6 #1 [ 417.121243] Hardware name: GIGABYTE R152-P31-00/MP32-AR1-00, BIOS F31n (SCP: 2.10.20220810) 09/30/2022 [ 417.130534] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 417.137483] pc : scsi_alloc_sgtables+0x310/0x350 [ 417.142088] lr : scsi_alloc_sgtables+0x90/0x350 [ 417.146605] sp : ffff8000874eb320 [ 417.149907] x29: ffff8000874eb340 x28: ffff07ffee061a00 x27: ffff07ffedb16c00 [ 417.157030] x26: ffff07ffec440000 x25: 0000000000000008 x24: 0000000000000000 [ 417.164152] x23: ffff080087b260d8 x22: ffff07ffec440000 x21: 0000000000000004 [ 417.171274] x20: ffff080087b25f00 x19: ffff080087b26010 x18: ffffb5fd2a5a1538 [ 417.178397] x17: 0000000000000400 x16: fffffe1fbeead042 x15: 0000000000000c00 [ 417.185519] x14: 0000000000000fff x13: ffffb5fd2a5a1000 x12: 0000000000000004 [ 417.192641] x11: 0000000000000000 x10: 0000000000000c00 x9 : 0000000000001000 [ 417.199764] x8 : ffff080087b2617c x7 : 0000000000000c00 x6 : 0000000000000000 [ 417.206888] x5 : 0000000000001000 x4 : 0000000000000001 x3 : ffff8000874eb330 [ 417.214010] x2 : 0000000000002302 x1 : 0000000000000000 x0 : 0000000000000002 [ 417.221133] Call trace: [ 417.223566] scsi_alloc_sgtables+0x310/0x350 [ 417.227823] sd_setup_read_write_cmnd+0x98/0x660 [ 417.232428] sd_init_command+0x84/0x4f0 [ 417.236252] scsi_prepare_cmd+0x134/0x1d0 [ 417.240249] scsi_queue_rq+0x3d0/0x4a0 [ 417.243985] blk_mq_dispatch_rq_list+0x118/0x500 [ 417.248590] __blk_mq_do_dispatch_sched+0x330/0x350 [ 417.253455] __blk_mq_sched_dispatch_requests+0x170/0x1c0 [ 417.258841] blk_mq_sched_dispatch_requests+0x34/0x80 [ 417.263880] blk_mq_run_hw_queue+0x1ac/0x1d0 [ 417.268137] blk_mq_dispatch_plug_list+0x164/0x2c8 [ 417.272915] blk_mq_flush_plug_list.part.0+0x44/0x178 [ 417.277953] blk_mq_flush_plug_list+0x24/0x40 [ 417.282298] __blk_flush_plug+0x110/0x180 [ 417.286294] __submit_bio+0x1b0/0x230 [ 417.289943] submit_bio_noacct_nocheck+0x144/0x268 [ 417.294721] submit_bio_noacct+0x144/0x5e8 [ 417.298805] submit_bio+0xc0/0x250 [ 417.302193] submit_bio_wait+0x5c/0xb0 [ 417.305930] __blkdev_direct_IO_simple+0x10c/0x238 [ 417.310708] blkdev_direct_IO+0x144/0x188 [ 417.314705] blkdev_write_iter+0x1d0/0x2a8 [ 417.318788] vfs_write+0x24c/0x380 [ 417.322178] ksys_pwrite64+0x84/0xd0 [ 417.325740] __arm64_sys_pwrite64+0x28/0x40 [ 417.329910] invoke_syscall+0x74/0x100 [ 417.333646] el0_svc_common.constprop.0+0xc8/0xf0 [ 417.338337] do_el0_svc+0x24/0x38 [ 417.341639] el0_svc+0x3c/0x158 [ 417.344768] el0t_64_sync_handler+0x120/0x138 [ 417.349112] el0t_64_sync+0x194/0x198 [ 417.352762] Code: 52800156 17ffff87 52800136 17ffff85 (d4210000) [ 417.358843] ---[ end trace 0000000000000000 ]--- [ 417.363447] Kernel panic - not syncing: Oops - BUG: Fatal exception [ 417.369700] SMP: stopping secondary CPUs [ 417.373935] Kernel Offset: 0x35fca88f0000 from 0xffff800080000000 [ 417.380015] PHYS_OFFSET: 0x80000000 [ 417.383490] CPU features: 0x00,0000010b,80140528,4241720b [ 417.388875] Memory Limit: none [ 417.391917] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- -- Best Regards, Yi Zhang . From: Christoph Hellwig To: axboe@kernel.dk Cc: linux-block@vger.kernel.org, Yi Zhang , Chaitanya Kulkarni Subject: [PATCH] block: take offset into account in blk_bvec_map_sg again Date: Tue, 9 Jul 2024 09:01:25 +0200 Message-ID: <20240709070126.3019940-1-hch@lst.de> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93947 Newsgroups: org.kernel.vger.linux-block Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail The rebase of commit 09595e0c9d65 ("block: pass a phys_addr_t to get_max_segment_size") lost adding the total to to the offset in blk_bvec_map_sg. Add it back. Fixes: 09595e0c9d65 ("block: pass a phys_addr_t to get_max_segment_size") Reported-by: Yi Zhang Reported-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig --- block/blk-merge.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/blk-merge.c b/block/blk-merge.c index e41ea331809936..048d07a5091f79 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -491,8 +491,8 @@ static unsigned blk_bvec_map_sg(struct request_queue *q, while (nbytes > 0) { unsigned offset = bvec->bv_offset + total; - unsigned len = get_max_segment_size(&q->limits, bvec_phys(bvec), - nbytes); + unsigned len = get_max_segment_size(&q->limits, + bvec_phys(bvec) + total, nbytes); struct page *page = bvec->bv_page; /* -- 2.43.0 . From: "lixianming.19951001" To: mst@redhat.com, jasowang@redhat.com, pbonzini@redhat.com Cc: virtualization@lists.linux.dev, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, lixianming Subject: [PATCH] virtio_blk: stop all virtqueues when 'virtblk_probe' fails Date: Tue, 9 Jul 2024 15:50:53 +0800 Message-Id: <20240709075053.811-1-lixianming.19951001@bytedance.com> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93949 org.kernel.vger.linux-kernel:1271517 Newsgroups: org.kernel.vger.linux-block,dev.linux.lists.virtualization,org.kernel.vger.linux-kernel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: lixianming We have already enabled the queue in 'init_vq', so we should stop all the virtqueues, just as we do in 'virtblk_remove', when 'virtblk_probe' fails Signed-off-by: lixianming --- drivers/block/virtio_blk.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 2351f411fa46..fb702be291c2 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -1559,6 +1559,8 @@ static int virtblk_probe(struct virtio_device *vdev) out_free_tags: blk_mq_free_tag_set(&vblk->tag_set); out_free_vq: + virtio_reset_device(vdev); + vblk->vdev = NULL; vdev->config->del_vqs(vdev); kfree(vblk->vqs); out_free_vblk: -- 2.20.1 . From: Zhiguo Niu To: , , CC: , , , , , , Subject: [PATCH V2] block: uapi: Fix compliation warning of using IOPRIO_PRIO_DATA Date: Tue, 9 Jul 2024 17:51:52 +0800 Message-ID: <1720518712-28301-1-git-send-email-zhiguo.niu@unisoc.com> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93952 org.kernel.vger.linux-kernel:1271736 Newsgroups: org.kernel.vger.linux-block,org.kernel.vger.linux-kernel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Generally, the input of IOPRIO_PRIO_DATA has 16 bits. If use format "%d" to printk IOPRIO_PRIO_DATA, there will be the following warning or error. fs/f2fs/sysfs.c:348:31: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=] return sysfs_emit(buf, "%s,%d\n", ~^ %ld This is because the output of IOPRIO_PRIO_DATA is converted to "UL" from IOPRIO_PRIO_MASK, which is not reasonable. unsigned int is more suitable. Fixes: 06447ae5e33b ("ioprio: move user space relevant ioprio bits to UAPI includes") Cc: stable@vger.kernel.org Cc: Oliver Hartkopp Signed-off-by: Zhiguo Niu Reviewed-by: Bart Van Assche Link: https://lore.kernel.org/all/1717155071-20409-1-git-send-email-zhiguo.niu@unisoc.com --- v2: add Fixes tag and Cc tag --- --- include/uapi/linux/ioprio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/ioprio.h b/include/uapi/linux/ioprio.h index bee2bdb0..9ead07f 100644 --- a/include/uapi/linux/ioprio.h +++ b/include/uapi/linux/ioprio.h @@ -11,7 +11,7 @@ #define IOPRIO_CLASS_SHIFT 13 #define IOPRIO_NR_CLASSES 8 #define IOPRIO_CLASS_MASK (IOPRIO_NR_CLASSES - 1) -#define IOPRIO_PRIO_MASK ((1UL << IOPRIO_CLASS_SHIFT) - 1) +#define IOPRIO_PRIO_MASK ((1U << IOPRIO_CLASS_SHIFT) - 1) #define IOPRIO_PRIO_CLASS(ioprio) \ (((ioprio) >> IOPRIO_CLASS_SHIFT) & IOPRIO_CLASS_MASK) -- 1.9.1 . From: John Garry To: axboe@kernel.dk, hch@lst.de Cc: linux-block@vger.kernel.org, John Garry Subject: [PATCH RFC 00/11] block debugfs: Catch missing flag array members Date: Tue, 9 Jul 2024 11:05:27 +0000 Message-Id: <20240709110538.532896-1-john.g.garry@oracle.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.linux-block:93953 Newsgroups: org.kernel.vger.linux-block Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Currently we rely on the developer to add the appropriate entry to the debugfs flag array when we add a new member. This has shown to be error prone. As an attempt to solve this problem, add compile-time assertions that we are not missing flag array entries. This should solve the problem that we don't miss entries, but we still rely on the developer to add in the proper order. Marking as an RFC as I am not sure if this is the best approach. And the enum-related changes will require further work, I think. Christoph Hellwig (1): block: remove QUEUE_FLAG_STOPPED John Garry (10): block: Make QUEUE_FLAG_x as an enum block: Add build-time assert for size of blk_queue_flag_name[] block: Catch possible entries missing from hctx_state_name[] block: Catch possible entries missing from hctx_flag_name[] block: Catch possible entries missing from alloc_policy_name[] block: Add missing entries from cmd_flag_name[] block: Catch possible entries missing from cmd_flag_name[] block: Make RQF_x as an enum block: Add zone write plugging entry to rqf_name[] block: Catch possible entries missing from rqf_name[] block/blk-mq-debugfs.c | 20 +++++++-- include/linux/blk-mq.h | 88 +++++++++++++++++++++++---------------- include/linux/blk_types.h | 1 + include/linux/blkdev.h | 31 +++++++------- 4 files changed, 86 insertions(+), 54 deletions(-) -- 2.31.1 . IronPort-SDR: 668d22e3_XHBJFzmGfDX1t9LmiI8Xc6eVl4uyQ+/GS6Wl3bD3brzh1Ln +9eB59pSlcRE4BOR869buN7httfSOXxuJ+LjctQ== WDCIronportException: Internal From: Shin'ichiro Kawasaki To: linux-block@vger.kernel.org Cc: Bryan Gurney , Shin'ichiro Kawasaki Subject: [PATCH blktests] dm/002: repeat dmsetup remove command on failure with EBUSY Date: Tue, 9 Jul 2024 21:44:41 +0900 Message-ID: <20240709124441.139769-1-shinichiro.kawasaki@wdc.com> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93969 Newsgroups: org.kernel.vger.linux-block Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail The test case dm/002 rarely fails with the message below: dm/002 => nvme0n1 (dm-dust general functionality test) [failed] runtime 0.204s ... 0.174s --- tests/dm/002.out 2024-06-14 14:37:40.480794693 +0900 +++ /home/shin/Blktests/blktests/results/nvme0n1/dm/002.out.bad 2024-06-14 21:38:18.588976499 +0900 @@ -7,4 +7,6 @@ countbadblocks: 0 badblock(s) found countbadblocks: 3 badblock(s) found countbadblocks: 0 badblock(s) found +device-mapper: remove ioctl on dust1 failed: Device or resource busy +Command failed. Test complete modprobe: FATAL: Module dm_dust is in use. This failure happens at "dmsetup remove" command, when the previous operation on the dm device is still ongoing. In this case, dm_open_count() is non-zero, then IOCTL for device remove fails and EBUSY is returned. To avoid the failure, retry the "dmsetup remove" command when it fails with EBUSY. Introduce the helper function _dm_remove for this purpose. Signed-off-by: Shin'ichiro Kawasaki --- This patch addresses a failure found during the debug work for another dm/002 failure [1]. [1] https://lore.kernel.org/linux-block/42ecobcsduvlqh77iavjj2p3ewdh7u4opdz4xruauz4u5ddljz@yr7ye4fq72tr/ tests/dm/002 | 2 +- tests/dm/rc | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/tests/dm/002 b/tests/dm/002 index fae3986..8ae8438 100755 --- a/tests/dm/002 +++ b/tests/dm/002 @@ -37,7 +37,7 @@ test_device() { sync dmsetup message dust1 0 countbadblocks sync - dmsetup remove dust1 + _dm_remove dust1 echo "Test complete" } diff --git a/tests/dm/rc b/tests/dm/rc index 0486db0..21a35f6 100644 --- a/tests/dm/rc +++ b/tests/dm/rc @@ -11,3 +11,26 @@ group_requires() { _have_program dmsetup _have_driver dm-mod } + +_dm_remove() { + local dm_dev=${1} + local i out + + # Retry dmsetup remove command in case it fails with EBUSY because of + # non-zero dm open count. + for ((i = 0; i < 10; i++)); do + if out=$(dmsetup remove "${dm_dev}" 2>&1); then + break + fi + echo "$out" >> "$FULL" + if ! [[ $out =~ "Device or resource busy" ]]; then + echo "$out" + break + fi + sleep 1 + done + if ((i == 10)); then + echo "dmsetup remove failed with EBUSY" + fi + +} -- 2.45.2 . From: Dongsheng Yang To: axboe@kernel.dk, dan.j.williams@intel.com, gregory.price@memverge.com, John@groves.net, Jonathan.Cameron@Huawei.com, bbhushan2@marvell.com, chaitanyak@nvidia.com, rdunlap@infradead.org Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, Dongsheng Yang Subject: [PATCH v1 0/7] Introduce CBD (CXL Block Device) Date: Tue, 9 Jul 2024 13:03:36 +0000 Message-Id: <20240709130343.858363-1-dongsheng.yang@linux.dev> X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-block:93970 org.kernel.vger.linux-cxl:29354 org.kernel.vger.linux-kernel:1272049 Newsgroups: org.kernel.vger.linux-block,org.kernel.vger.linux-cxl,org.kernel.vger.linux-kernel Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi all, This is V1 for CXL Block Device. This patchset is based on v6.9 and it's available at: https://github.com/DataTravelGuide/linux branch cbd. changes from RFC: (https://lore.kernel.org/lkml/20240422071606.52637-1-dongsheng.yang@easystack.cn/) (1) only support hardware-consistency cxl shared memory. As discussed in the RFC, the current cbd only supports hardware-consistency for CXL shared memory, and some code related to software-consistency support has been removed from the RFC. In the current tests, whether using local PMEM or QEMU-simulated shared memory devices, they all are hardware-consistency. (2) add a segment abstraction for transport data space management. The layout of the transport remains essentially unchanged, with the only difference being the addition of a segment abstraction for scalability purposes. A channel is a type of segment used for data transfer between the blkdev and the backend. In the future, there will be more segment types, such as a cache segment for caching data for the blkdev. (3) add CONFIG_CBD_CRC option in Kconfig We only support hardware-consistency, so theoretically, there should be no data consistency issues when transferring data between blkdev and the backend. However, cbd provides a verification mechanism, offering CRC checks for both metadata and data to verify after data reception. This method impacts performance, so it is an option in Kconfig. (4) allow user to clear dead object in transport metadata When a host using cbd, whether backend or blkdev, dies without unregistering, the metadata in the transport will retain some dead information. In v1, users are allowed to clear this dead metadata via sysfs. Of course, there is a heartbeat mechanism to ensure users do not mistakenly delete alive metadata. (5) allow user to force stop blkdev and reattach backend This also handles scenarios where the host goes offline unexpectedly. When the backend goes offline unexpectedly, the corresponding blkdev might have I/O operations that cannot finish. In such cases, cbd provides two ways to handle this: a) If the backend can recover, we can re-add the backend to the corresponding transport, allowing the blkdev's I/O operations to continue being processed. b) If the backend cannot recover, the blkdev can be force-stopped, and the incomplete I/O operations will return EIO, but they will no longer remain blocked. (6) dont allocate new pages in hander for bio data. The backend handler does not allocate pages for bio. Instead, the handler can directly map the data pages from the transport to the bio, and then send the bio to the backend disk, achieving zero copy on the backend side. (7) new test project cbd-tests: cbd-tests (https://github.com/DataTravelGuide/cbd-tests), for testing cbd. It is an automated testing project based on the Avocado testing framework. Currently, it includes xfstests on cbd block devices with XFS, V1 Passed all 944 tests in xfstests (https://datatravelguide.github.io/dtg-blog/cbd/test-results/test_result_v1/test-results/xfstests-1-xfstests.py_Xfstests.test_run-cbdd_timeout-no_timeout-disk_type-fs_type-fs_xfs-f090/debug.log). as well as fio performance testing directly on /dev/cbdX block devices. The test results can be viewed here in [test results]: https://datatravelguide.github.io/dtg-blog/cbd/cbd.html#test-results Thanx Dongsheng Yang (7): cbd: introduce cbd_transport cbd: introduce cbd_host cbd: introduce cbd_segment cbd: introduce cbd_channel cbd: introduce cbd_blkdev cbd: introduce cbd_backend block: Init for CBD(CXL Block Device) module drivers/block/Kconfig | 2 + drivers/block/Makefile | 2 + drivers/block/cbd/Kconfig | 23 + drivers/block/cbd/Makefile | 3 + drivers/block/cbd/cbd_backend.c | 296 ++++++++++ drivers/block/cbd/cbd_blkdev.c | 417 ++++++++++++++ drivers/block/cbd/cbd_channel.c | 153 ++++++ drivers/block/cbd/cbd_handler.c | 263 +++++++++ drivers/block/cbd/cbd_host.c | 128 +++++ drivers/block/cbd/cbd_internal.h | 848 ++++++++++++++++++++++++++++ drivers/block/cbd/cbd_main.c | 224 ++++++++ drivers/block/cbd/cbd_queue.c | 526 ++++++++++++++++++ drivers/block/cbd/cbd_segment.c | 108 ++++ drivers/block/cbd/cbd_transport.c | 883 ++++++++++++++++++++++++++++++ 14 files changed, 3876 insertions(+) create mode 100644 drivers/block/cbd/Kconfig create mode 100644 drivers/block/cbd/Makefile create mode 100644 drivers/block/cbd/cbd_backend.c create mode 100644 drivers/block/cbd/cbd_blkdev.c create mode 100644 drivers/block/cbd/cbd_channel.c create mode 100644 drivers/block/cbd/cbd_handler.c create mode 100644 drivers/block/cbd/cbd_host.c create mode 100644 drivers/block/cbd/cbd_internal.h create mode 100644 drivers/block/cbd/cbd_main.c create mode 100644 drivers/block/cbd/cbd_queue.c create mode 100644 drivers/block/cbd/cbd_segment.c create mode 100644 drivers/block/cbd/cbd_transport.c -- 2.34.1 .