linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, guaneryu@gmail.com
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me
Subject: [PATCH 2/2] scsi_debug: fix module removal loop
Date: Tue, 17 Aug 2021 16:53:10 -0700	[thread overview]
Message-ID: <162924439095.779373.7171773658755331729.stgit@magnolia> (raw)
In-Reply-To: <162924437987.779373.1973564511078951065.stgit@magnolia>

From: Darrick J. Wong <djwong@kernel.org>

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@kernel.org>
---
 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"
 }


  parent reply	other threads:[~2021-08-17 23:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 23:52 [PATCHSET 0/2] fstests: random fixes Darrick J. Wong
2021-08-17 23:53 ` [PATCH 1/2] xfs/176: fix the group name Darrick J. Wong
2021-08-18  3:02   ` Zorro Lang
2021-08-17 23:53 ` Darrick J. Wong [this message]
2021-08-18  3:55   ` [PATCH 2/2] scsi_debug: fix module removal loop Zorro Lang
2021-08-22 12:19   ` Eryu Guan

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=162924439095.779373.7171773658755331729.stgit@magnolia \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=guaneryu@gmail.com \
    --cc=linux-xfs@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).