On 7/17/25 6:16 AM, Yi Zhang wrote: > > Sorry for the late response, it takes me some time to find which case > triggered the kmemleak. > It turns out that block/040[1] triggered the kmemleak, and just > running [2] after block/040 can not trigger the kmemleak immediately. > We have to wait for more time. > [1] > [ 458.175983] null_blk: disk nullb0 created > [ 458.180035] null_blk: module loaded > [ 458.397994] run blktests block/040 at 2025-07-16 20:31:20 > [ 458.571488] null_blk: disk nullb1 created > [ 874.620574] kmemleak: 522 new suspected memory leaks (see > /sys/kernel/debug/kmemleak) > [2] > echo scan >/sys/kernel/debug/kmemleak > This brings to mind a potential improvement: why don’t we enable kmemleak checks in blktests? We could clear the kmemleak state at the beginning of each test, run the test, and then scan for any reported memory leaks. If kmemleak reports a leak, we could: - Mark the test as failed. - Append the leak details to the test log for later review. This would help catch resource leaks more proactively during automated testing. If all agrees, then I could workout a patch to blktests for the above improvement. Thanks, --Nilay
