https://bugzilla.kernel.org/show_bug.cgi?id=212337 --- Comment #10 from Luis Chamberlain (mcgrof@xxxxxxxxxx) --- (In reply to Luis Chamberlain from comment #9) > (In reply to d gilbert from comment #8) > > > >> The scsi_debug module option that is already in place is: > > >> tur_ms_to_ready: TEST UNIT READY millisecs before initial good > status > > >> (def=0) > > > > You asked how it works, try: > > modprobe scsi_debug tur_ms_to_ready=20000 > > > > That does not resolve the rmmod race against insmod: > > scsi host2: scsi_debug: version 0190 [20200710] > [ 42.213400] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0 > [ 42.217527] scsi 2:0:0:0: Direct-Access Linux scsi_debug > 0190 PQ: 0 ANSI: 7 > [ 42.223346] scsi 2:0:0:0: Attached scsi generic sg0 type 0 > [ 42.282195] scsi host2: scsi_debug: version 0190 [20200710] > [ 42.282195] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0 > [ 42.288169] scsi 2:0:0:0: Direct-Access Linux scsi_debug > 0190 PQ: 0 ANSI: 7 > [ 42.292122] sd 2:0:0:0: Attached scsi generic sg0 type 0 > [ 42.292244] sd 2:0:0:0: Power-on or device reset occurred > [ 42.302288] sd 2:0:0:0: [sda] Spinning up disk... > > Then we wait... > > [ 44.308213] ...................ready > [ 62.748919] sd 2:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 > MB/8.00 MiB) > [ 62.754265] sd 2:0:0:0: [sda] Write Protect is off > [ 62.763253] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, > supports DPO and FUA > [ 62.776965] sd 2:0:0:0: [sda] Optimal transfer size 524288 bytes > [ 62.883817] sd 2:0:0:0: [sda] Attached SCSI disk > > And then rmmod still fails. Using udevadm settle (as used in blktests) after modprobe and before rmmod fixes the issue. I tested modprobe udevadm settle; rmmod scsi_debug loop 5000 so far without issue. I however note that we send uevents via kobject_uevent_net_broadcast() and that's a no-op for kernels without CONFIG_NET, and so this is not a true global solution either. Udev events are sent via netlink to userspace, and udev in userspace is in charge of handling the events. The command udevadm settle just checks if /run/udev/queue is 0. There is currently nothing we can do on scsi_debug to do something similar on init. #!/bin/bash LOOP=1 while true; do modprobe scsi_debug if [[ $? -ne 0 ]]; then echo "scsi_debug modprobe failed at count $LOOP" exit 1 fi udevadm settle rmmod scsi_debug if [[ $? -ne 0 ]]; then echo "scsi_debug rmmod failed at count $LOOP" exit 1 else echo "Loop $LOOP: OK!" fi let LOOP=$LOOP+1 done I should note that this works even if one either delays async probe on sd.c, and/or also augments the delay and delays scheduling the probe as follows: diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 9179825ff646..b9ae63c17cb6 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -1071,6 +1071,7 @@ static int __driver_attach(struct device *dev, void *data) } /* ret > 0 means positive match */ if (driver_allows_async_probing(drv)) { + ssleep(5); /* * Instead of probing the device synchronously we will * probe it asynchronously to allow for more parallelism. diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index ed0b1bb99f08..79fc834073af 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3371,6 +3371,7 @@ static int sd_probe(struct device *dev) int index; int error; + ssleep(3); scsi_autopm_get_device(sdp); error = -ENODEV; if (sdp->type != TYPE_DISK && Using wait_for_device_probe() on scsi_debug's driver init doesn't fix this either. And so I think we're stuck with userspace having to call udevadm settle after modprobe and before rmmod as well. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
