Re: [bug report] kmemleak issue observed during blktests

[Nilay Shroff <nilay@linux.ibm.com>]

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