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

[Eryu Guan <guan@eryu.me>]

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