From: Eryu Guan <guan@eryu.me>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: fstests@vger.kernel.org, hare@suse.de, dgilbert@interlog.com,
jeyu@kernel.org, lucas.demarchi@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] common/scsi_debug: use the patient module remover
Date: Sun, 15 Aug 2021 20:35:02 +0800 [thread overview]
Message-ID: <YRkJ9rkFPyYUy8p5@desktop> (raw)
In-Reply-To: <20210811154512.1813622-4-mcgrof@kernel.org>
On Wed, Aug 11, 2021 at 08:45:12AM -0700, Luis Chamberlain wrote:
> If you try to run tests such as generic/108 in a loop
> you'll eventually see a failure, but the failure can
> be a false positive and the test was just unable to remove
> the scsi_debug module.
>
> We need to give some time for the refcnt to become 0. For
> instance for the test generic/108 the refcnt lingers between
> 2 and 1. It should be 0 when we're done but a bit of time
> seems to be required. The chance of us trying to run rmmod
> when the refcnt is 2 or 1 is low, about 1/30 times if you
> run the test in a loop on linux-next today.
>
> Likewise, even when its 0 we just need a tiny breather before
> we can remove the module (sleep 10 suffices) but this is
> only required on older kernels. Otherwise removing the module
> will just fail.
>
> Some of these races are documented on the korg#212337, and
> Doug Gilbert has posted at least one patch attempt to try
> to help with this [1]. The patch does not resolve all the
> issues though, it helps though.
>
> [0] https://bugzilla.kernel.org/show_bug.cgi?id=212337
> [1] https://lkml.kernel.org/r/20210508230745.27923-1-dgilbert@interlog.com
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
> common/scsi_debug | 6 ++++--
There're also some "modprobe -r" calls in common/module, should the be
replaced with _patient_rmmod as well?
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/common/scsi_debug b/common/scsi_debug
> index e7988469..3c9cd820 100644
> --- a/common/scsi_debug
> +++ b/common/scsi_debug
> @@ -4,11 +4,13 @@
> #
> # Functions useful for tests on unique block devices
>
> +. common/module
> +
> _require_scsi_debug()
> {
> # make sure we have the module and it's not already used
> modinfo scsi_debug 2>&1 > /dev/null || _notrun "scsi_debug module not found"
> - lsmod | grep -wq scsi_debug && (rmmod scsi_debug || _notrun "scsi_debug module in use")
> + lsmod | grep -wq scsi_debug && (_patient_rmmod scsi_debug || _notrun "scsi_debug module in use")
I don't think we should use _patient_rmmod here, if we set timeout to
forever and there's actually some other process using scsi_debug module,
we'll loop forever here. And a failure to remove scsi_debug only results
in _notrun, and won't cause false test failure.
> # make sure it has the features we need
> # logical/physical sectors plus unmap support all went in together
> modinfo scsi_debug | grep -wq sector_size || _notrun "scsi_debug too old"
> @@ -53,5 +55,5 @@ _put_scsi_debug_dev()
> $UDEV_SETTLE_PROG
> n=$((n-1))
> done
I think the above while loop could be removed as well?
Thanks,
Eryu
> - rmmod scsi_debug || _fail "Could not remove scsi_debug module"
> + _patient_rmmod scsi_debug || _fail "Could not remove scsi_debug module"
> }
> --
> 2.30.2
next prev parent reply other threads:[~2021-08-15 12:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 15:45 [PATCH v2 0/3] fstests: add patient module remover Luis Chamberlain
2021-08-11 15:45 ` [PATCH v2 1/3] fstests: use udevadm settle after pvremove Luis Chamberlain
2021-08-15 12:36 ` Eryu Guan
2021-08-11 15:45 ` [PATCH v2 2/3] common/module: add patient module rmmod support Luis Chamberlain
2021-08-15 12:29 ` Eryu Guan
2021-08-18 14:02 ` Luis Chamberlain
2021-08-19 2:26 ` Eryu Guan
2021-08-19 23:58 ` Luis Chamberlain
2021-08-11 15:45 ` [PATCH v2 3/3] common/scsi_debug: use the patient module remover Luis Chamberlain
2021-08-15 12:35 ` Eryu Guan [this message]
2021-08-20 0:33 ` Luis Chamberlain
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=YRkJ9rkFPyYUy8p5@desktop \
--to=guan@eryu.me \
--cc=dgilbert@interlog.com \
--cc=fstests@vger.kernel.org \
--cc=hare@suse.de \
--cc=jeyu@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=mcgrof@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.