* blktests failures with v7.4-rc1 kernel
@ 2026-11-08 13:08 Shin'ichiro Kawasaki
0 siblings, 0 replies; only message in thread
From: Shin'ichiro Kawasaki @ 2026-11-08 13:08 UTC (permalink / raw)
To: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, nbd, linux-rdma
Hi all,
I ran the latest blktests (git hash: a65cf6bdca19) with the v7.4-rc1 kernel. I
observed 4 failures listed below. Compared with the previous report for v7.3
kernel [1], 2 new failure was observed. The failure #4 nvme/059 needs further
work. Help for it will be appreciated.
[1] https://lore.kernel.org/linux-block/atgwg4i6C1zGi1HU@shinmob/
List of failures
================
#1: nvme/004,031 (rdma transport)
#2: nvme/037 hang (new)(rdma transport)
#3: nvme/052
#4: nvme/059 (new)(fc transport)(kmemleak)
Failure description
===================
#1: nvme/004,031 (rdma transport)
The test cases nvme/004 and nvme/031 fail occasionally for rdma transport
due to the lockdep WARN related to the two locks nvmet_config_sem and
&id_priv->handler_mutex. It is easier to recreate with rxe driver. It is
rather rare, but the failure is observed with siw driver also.
The trigger commit was
2a8513091d2f ("nvme-rdma: parallelize I/O queue allocation and startup")
in v7.3-rc1. I posted fix patch candidate [2].
[2] https://lore.kernel.org/linux-nvme/20261108120154.148824-1-shinichiro.kawasaki@wdc.com/
#2: nvme/037 hang (rdma transport)
When the test case nvme/037 is repeated several times for rdma transport,
it hangs [3]. Nilay provided a fix patch, which was already applied for
v7.4-rcX [4].
[3] https://lore.kernel.org/linux-nvme/auhpmq499RVE9YpC@shinmob/
[4] https://lore.kernel.org/linux-nvme/20261105123642.2120548-2-nilay@linux.ibm.com/
#3: nvme/052
When it is repeated several times, the test case nvme/052 fails [5]. Nilay
provided a fix patch [6].
[5] https://lore.kernel.org/all/ar30Q5H1fuyFtDwM@shinmob/
[6] https://lore.kernel.org/linux-nvme/20261002070249.338225-1-nilay@linux.ibm.com/
#4: nvme/059 (fc transport)(kmemleak)
When the test cases nvme/057, 058 and 059 are repeated several times for
fc transport, a kmemleak was reported at the test case nvme/059:
unreferenced object 0xffff88812a768000 (size 512):
comm "kworker/1:3H", pid 92985, jiffies 4301970763
hex dump (first 32 bytes):
40 cd f8 4b 81 88 ff ff 00 00 00 00 00 00 00 00 @..K............
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
backtrace (crc 3cd92a37):
__kmalloc_cache_noprof+0x4c1/0x6d0
fcloop_fcp_req+0xc4/0x650 [nvme_fcloop]
nvme_fc_start_fcp_op.part.0+0x642/0x17a0 [nvme_fc]
nvme_fc_queue_rq+0x392/0x6e0 [nvme_fc]
blk_mq_dispatch_rq_list+0x3e0/0x2400
__blk_mq_sched_dispatch_requests+0x20a/0x15d0
blk_mq_sched_dispatch_requests+0xab/0x150
blk_mq_run_work_fn+0x1dc/0x2e0
process_one_work+0x944/0x1760
worker_thread+0x5fd/0xfe0
kthread+0x36d/0x470
ret_from_fork+0x653/0x9d0
ret_from_fork_asm+0x1a/0x30
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-11-08 13:08 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-08 13:08 blktests failures with v7.4-rc1 kernel Shin'ichiro Kawasaki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.