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

Chaitanya Kulkarni
2024-12-03T08:26:57Z

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