[PATCHSET 0/2] fstests: random fixes

[PATCHSET 0/2] fstests: random fixes

[Darrick J. Wong]

Hi all,

Here are the usual weekly fixes for fstests.

If you're going to start using this mess, you probably ought to just
pull from my git trees, which are linked below.

This is an extraordinary way to destroy everything.  Enjoy!
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=random-fixes

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=random-fixes

fstests git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=random-fixes
---
 common/scsi_debug |    4 ++--
 tests/xfs/176     |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 1/2] xfs/176: fix the group name

[Darrick J. Wong]

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

Filesystem shrink tests for xfs are supposed to be in the 'shrinkfs'
group, not 'shrink'.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/176 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/tests/xfs/176 b/tests/xfs/176
index ce9965c2..ba4aae59 100755
--- a/tests/xfs/176
+++ b/tests/xfs/176
@@ -8,7 +8,7 @@
 # of the filesystem is now in the middle of a sparse inode cluster.
 #
 . ./common/preamble
-_begin_fstest auto quick shrink
+_begin_fstest auto quick shrinkfs
 
 # Import common functions.
 . ./common/filter

Re: [PATCH 1/2] xfs/176: fix the group name

[Zorro Lang]

On Tue, Aug 17, 2021 at 04:53:05PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Filesystem shrink tests for xfs are supposed to be in the 'shrinkfs'
> group, not 'shrink'.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---

Yes, you're right:

[zorro@zlang-laptop xfstests-dev]$ grep -rsn _begin_fstest tests/|grep shrink
tests/xfs/176:11:_begin_fstest auto quick shrink
tests/xfs/163:13:_begin_fstest auto quick growfs shrinkfs
tests/xfs/168:14:_begin_fstest auto growfs shrinkfs ioctl prealloc stress

Reviewed-by: Zorro Lang <zlang@redhat.com>

>  tests/xfs/176 |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> diff --git a/tests/xfs/176 b/tests/xfs/176
> index ce9965c2..ba4aae59 100755
> --- a/tests/xfs/176
> +++ b/tests/xfs/176
> @@ -8,7 +8,7 @@
>  # of the filesystem is now in the middle of a sparse inode cluster.
>  #
>  . ./common/preamble
> -_begin_fstest auto quick shrink
> +_begin_fstest auto quick shrinkfs
>  
>  # Import common functions.
>  . ./common/filter
> 

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

[Darrick J. Wong]

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

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

[Zorro Lang]

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>

>  }
> 

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

[Eryu Guan]

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