Re: [PATCH v4 1/2] blktests: replace module removal with patient module removal

[Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>]

On Dec 22, 2025 / 18:11, Swarna Prabhu wrote:
> On Fri, Dec 19, 2025 at 05:29:06AM +0000, Shinichiro Kawasaki wrote:
> > On 11/27/25 2:45 AM, Bart Van Assche wrote:
> > > On 11/26/25 9:11 AM, Luis Chamberlain wrote:
> > >> Long ago a WAIT option for module removal was added... that was then
> > >> removed as it was deemed not needed as folks couldn't figure out when
> > >> these races happened. The races are actually pretty easy to trigger, it
> > >> was just never properly documented. A simpe blkdev_open() will easily
> > >> bump a module refcnt, and these days many thing scan do that sort of
> > >> thing.
> > > 
> > > It would be appreciated if "thing" could be replaced with a more
> > > specific description of what actually happens.
> > >> The proper solution is to implement then a patient module removal
> > >> on kmod and that has been merged now as modprobe --wait=MSEC option.
> > >> We need a work around to open code a similar solution for users of
> > >> old versions of kmod. An open coded solution for fstests exists
> > >> there for over a year now. This now provides the respective blktests
> > >> implementation.
> > > 
> > > How can it be concluded what the proper solution is without explaining
> > > the root cause first? Please add an explanation of the root cause. I
> > > assume that the root cause is that some references are dropped
> > > asynchronously after module removal has been requested for the first
> > > time?
> > 
> > I agree that the clarification on the above points will improve the commit
> > message. Said that, I do not think lack of the clarifications should delay the
> > application of this series.
> > 
> > Swarna, Luis, if there is any URL to the "flaky bug" that Swaran faced, please
> > share. I can add it as a Link tag to show another reason for this series.
> >
> 
> I donot have any URL to the bug, but below is the description for it: 
> 
> I had seen a sporadic kernel hang  while running block tests (block/003) when testing  
> scsi driver with sector size 16k which is detailed in the  testing description of the 
> cover letter sent for RFC v1 series for scsi fix. 
> (link here- https://lore.kernel.org/all/20251202021522.188419-1-sw.prabhu6@gmail.com/ ).
> The fio task triggerd at test block/003 would race with udevs generated while stressing 
> scsi debug module in test - block/001.
> 
> I havent been able to reproduce the hang in the current setup lately, so i pasted below the 
> snippet of the dmesg i had captured when the hang occured with block/003 test:
> 

Swarna, thanks for the description. The problem you faced looks like the same
problem that Luis described. I will amend the commit log to add the link to this
e-mail thread for recording.

As Luis described, the problem looks having multiple aspects, and this patient
module removal solution addresses one of the aspects. Another aspect I noticed
was that lots of udev events influence following test cases. Similar problem was
observed for loop/010 [*], and solution for loop/010 was disabling udev events
during the testcase run. At this moment, I think and hope this patient module
removal solution is enough for block/001, and there is no need to disable udev
events in block/001, probably.

[*] https://github.com/linux-blktests/blktests/issues/181