Re: [RFC] scsi_debug: add hosts initialization --> worker

[Luis Chamberlain <mcgrof@kernel.org>]

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@interlog.com>

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