[PATCH 2/2] scsi_debug: fix module removal loop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Darrick J. Wong <djwong@xxxxxxxxxx>

Luis' recent patch changing the "sleep 1" to a "udevadm settle"
invocation exposed some race conditions in _put_scsi_debug_dev that
caused regressions in generic/108 on my machine.  Looking at tracing
data, it looks like the udisks daemon will try to open the device at
some point after the filesystem unmounts; if this coincides with the
final 'rmmod scsi_debug', the test fails.

Examining the function, it is odd to me that the loop condition is
predicated only on whether or not modprobe /thinks/ it can remove the
module.  Why not actually try (twice) actually to remove the module,
and then complain if a third attempt fails?

Also switch the final removal attempt to modprobe -r, since it returns
zero if the module isn't loaded.

Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
---
 common/scsi_debug |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/common/scsi_debug b/common/scsi_debug
index e7988469..abaf6798 100644
--- a/common/scsi_debug
+++ b/common/scsi_debug
@@ -49,9 +49,9 @@ _put_scsi_debug_dev()
 	# use redirection not -q option of modprobe here, because -q of old
 	# modprobe is only quiet when the module is not found, not when the
 	# module is in use.
-	while [ $n -ge 0 ] && ! modprobe -nr scsi_debug >/dev/null 2>&1; do
+	while [ $n -ge 0 ] && ! modprobe -r scsi_debug >/dev/null 2>&1; do
 		$UDEV_SETTLE_PROG
 		n=$((n-1))
 	done
-	rmmod scsi_debug || _fail "Could not remove scsi_debug module"
+	modprobe -r scsi_debug || _fail "Could not remove scsi_debug module"
 }




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux