[Bug 212337] scsi_debug: race at module load and module unload

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=212337

--- Comment #10 from Luis Chamberlain (mcgrof@kernel.org) ---
(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.