| Message ID | 162924439095.779373.7171773658755331729.stgit@magnolia (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fstests: random fixes | expand |
On Tue, Aug 17, 2021 at 04:53:10PM -0700, Darrick J. Wong wrote: > 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" Make sense, I don't understand why we need "dry-run" modprobe at here either. Reviewed-by: Zorro Lang <zlang@redhat.com> > } >
On Tue, Aug 17, 2021 at 04:53:10PM -0700, Darrick J. Wong wrote: > 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)) Luis' new patch removed this while loop completely, and > done > - rmmod scsi_debug || _fail "Could not remove scsi_debug module" > + modprobe -r scsi_debug || _fail "Could not remove scsi_debug module" Replaced this rmmod with _patient_rmmod helper, which uses modprobe -r to remove mod internally. So I'd drop this patch. Thanks for the fix anyway! Eryu
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" }