From: Luis Chamberlain <mcgrof@kernel.org>
To: fstests@vger.kernel.org
Cc: hare@suse.de, dgilbert@interlog.com, jeyu@kernel.org,
lucas.demarchi@intel.com, linux-kernel@vger.kernel.org,
Luis Chamberlain <mcgrof@kernel.org>
Subject: [PATCH 0/4] scsi_debug: improve failure rates
Date: Tue, 27 Jul 2021 13:10:41 -0700 [thread overview]
Message-ID: <20210727201045.2540681-1-mcgrof@kernel.org> (raw)
When using scsi_debug to create virtual devices we can often run into
failures which are really just false positives, and the failure was the
inability to remove the module. Addressing this is not easy. While we
can learn from what blktests folks do and use udevadm settle, that's
not sufficient by any means. This addresses the other pieces needed.
More work is also needed on the scsi_debug driver front.
Makes me wonder if a patient kmod removal option is then desirable
upstream on kmod (just the one which waits to refcnt 0), given this sort
of test case. Lucas?
Luis Chamberlain (4):
common/config: disable udevadm settle if CONFIG_NET is disabled
common/scsi_debug: use udevadm settle instead of sleeping
common/module: add a patient module rmmod
common/scsi_debug: use the patient module remover
common/config | 9 ++++++++-
common/module | 48 +++++++++++++++++++++++++++++++++++++++++++++++
common/scsi_debug | 10 ++++++----
3 files changed, 62 insertions(+), 5 deletions(-)
--
2.29.2
next reply other threads:[~2021-07-27 20:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-27 20:10 Luis Chamberlain [this message]
2021-07-27 20:10 ` [PATCH 1/4] common/config: disable udevadm settle if CONFIG_NET is disabled Luis Chamberlain
2021-07-27 20:10 ` [PATCH 2/4] common/scsi_debug: use udevadm settle instead of sleeping Luis Chamberlain
2021-07-27 20:10 ` [PATCH 3/4] common/module: add a patient module rmmod Luis Chamberlain
2021-07-30 0:22 ` Luis Chamberlain
2021-08-10 21:31 ` Luis Chamberlain
2021-07-27 20:10 ` [PATCH 4/4] common/scsi_debug: use the patient module remover 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=20210727201045.2540681-1-mcgrof@kernel.org \
--to=mcgrof@kernel.org \
--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 \
/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.