[PATCH blktests 0/2] add nvme test for creating sleep while atomic kernel BUG

Chaitanya Kulkarni chaitanyak at nvidia.com
Tue Dec 3 00:26:47 PST 2024


On 12/2/24 21:38, Nilay Shroff wrote:
> Hitting the kernel BUG depends on the race. In the test case, we disable the target ns
> and then write to it and there's a time window between "disabling ns and writing to it".
> During this time window, after disabling ns but before we actually begin writing to it,
> if the target could clean up ns and remove it from subsystem Xarray then we may not hit
> this BUG. So I run the test case in a loop for 10 times hoping that we'd hit it at-least
> once. However, on my test system, I could hit it 2-3 times for each run of the test.

Thanks for the explanation, however we need a test that will hit the bug 
100% of the
time and will avoid different behavior when users run it multiple times.

Luis has shared his general experience running block test and conclusion 
was we need to
have tests that are consistent and not have different results when 
executed multiple
times. From the feedback we got we can't really guarantee that every 
user will know
this and or adjust the testcase running loop to hit the bug and run it 
for multiple
times, that brings down effectiveness of the test. Not only that it also 
becomes real
problem when to build a CI on the top of blktest.

How about we add an error injection code so it will prolong the race 
window in such
a way it will stop the target from cleaning up the namespace and 
removing it from
xarray when disable ns command is executed and then writing to it ? 
of-course
before disabling the ns we will have to enable the corresponding error 
injection code
potentially sleep.

This is guarantee that we will his the race window and make the test 
effective 100%
of the time.

Or there any other simple solution we can think of ?

-ck




More information about the Linux-nvme mailing list