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" }
