From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 212337] scsi_debug: race at module load and module unload
Date: Mon, 22 Mar 2021 18:21:33 +0000 [thread overview]
Message-ID: <bug-212337-11613-UOtFnr8hd3@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-212337-11613@https.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.
next prev parent reply other threads:[~2021-03-22 18:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 17:09 [Bug 212337] New: scsi_debug: race at module load and module unload bugzilla-daemon
2021-03-18 17:38 ` [Bug 212337] " bugzilla-daemon
2021-03-18 18:32 ` Douglas Gilbert
2021-03-18 17:43 ` bugzilla-daemon
2021-03-18 18:42 ` bugzilla-daemon
2021-03-18 19:14 ` bugzilla-daemon
2021-03-18 21:00 ` Douglas Gilbert
2021-03-18 19:20 ` bugzilla-daemon
2021-03-18 19:22 ` bugzilla-daemon
2021-03-18 19:57 ` bugzilla-daemon
2021-03-18 21:00 ` bugzilla-daemon
2021-03-22 16:23 ` bugzilla-daemon
2021-03-23 0:37 ` Douglas Gilbert
2021-03-22 18:21 ` bugzilla-daemon [this message]
2021-03-22 18:31 ` bugzilla-daemon
2021-03-23 0:38 ` bugzilla-daemon
2021-05-04 21:18 ` bugzilla-daemon
2021-05-05 15:57 ` Douglas Gilbert
2021-05-04 21:22 ` bugzilla-daemon
2021-05-05 16:06 ` bugzilla-daemon
2021-05-07 18:25 ` bugzilla-daemon
2021-05-07 20:46 ` Douglas Gilbert
2021-05-07 20:46 ` bugzilla-daemon
2021-05-07 22:37 ` bugzilla-daemon
2021-05-07 22:46 ` bugzilla-daemon
2021-07-27 19:27 ` bugzilla-daemon
2021-07-30 20:31 ` bugzilla-daemon
2021-08-10 5:19 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-212337-11613-UOtFnr8hd3@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).