On Fri, Mar 19, 2021 at 11:05:14AM -0400, Douglas Gilbert wrote: > Adding (pseudo) SCSI hosts has been done in the scsi_debug_init() > function. Each added SCSI host triggers an (async) scan and for > every LUN found, the host environment can trigger a lot of work. > On a recent Ubuntu/Debian distribution a lot of this "work" seems > to involve udev and its scripts. The result of this work can be > seconds elapsed before scsi_debug_init() returns. > > This experimental code places the function to add those SCSI hosts > in its own thread. This allows scsi_debug_init() to complete a lot > faster. To impede malevolent user space code that might try to send > a 'rmmod scsi_debug', an extra module_get() reference is taken > before the worker thread starts and that worker gives back that > reference when it completes. > > This patch is against MKP's repository and its 5.13/scsi-queue > branch which is sitting at lk 5.12.0-rc1. It should apply to later > release candidates in that series. > > Signed-off-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx> This is a good idea in general in terms of module design, however given current users include fstests and blktests I think as-is it would introduce a few false positives. So we either decide to not care about those users and force a check on version moving forward.. or we keep and the existing behaviour and bite the bullet long term. Also, in terms of design an alternative is a load/unload sysfs file. But we'd still punt the same issue of "are we ready to use these devices after load" to when this file completes writing to. FWIW, blktets users udevadm settle to try to ensure udev stuff completes its work, but if folks are using blktests to test things they may also have multipath installed, and for whatever reason that userspace application loves to tickle scsi devices upon load, and that is a random example of another user of of scsi devices which would prevent unload. Granted, the use of that application of opening the device is quick, but it still reveals an issue with testing. Perhaps all we can do is just use scsi_complete_async_scans() in a private module namespace as suggested in the bug report *and* perhaps setting TEST UNIT READY as you suggested? If setting TEST UNIT READY for until we're ready, perhaps that really suffices completely, and that would give parity with what other userspace applications would use for prepping for a test on a target scsi device. I'll soon test what you recommended of modprobe scsi_debug tur_ms_to_ready=20000 If more devices are used, perhaps the thing to do there is to multiply per numbef of devices requested? Luis
