From: Daniel Wagner <dwagner@suse.de>
To: James Smart <james.smart@broadcom.com>
Cc: Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>,
Hannes Reinecke <hare@suse.de>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Daniel Wagner <dwagner@suse.de>
Subject: [PATCH v5 01/12] nvme-fc: do not wait in vain when unloading module
Date: Wed, 31 Jan 2024 09:51:01 +0100 [thread overview]
Message-ID: <20240131085112.21668-2-dwagner@suse.de> (raw)
In-Reply-To: <20240131085112.21668-1-dwagner@suse.de>
The module exit path has race between deleting all controllers and
freeing 'left over IDs'. To prevent double free a synchronization
between nvme_delete_ctrl and ida_destroy has been added by the initial
commit.
There is some logic around trying to prevent from hanging forever in
wait_for_completion, though it does not handling all cases. E.g.
blktests is able to reproduce the situation where the module unload
hangs forever.
If we completely rely on the cleanup code executed from the
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
calling ida_destroy unnecessary. We only have to ensure that all
nvme_delete_ctrl code has been executed before we leave
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
workqueue.
While at it, remove the unused nvme_fc_wq workqueue too.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
---
drivers/nvme/host/fc.c | 47 ++++++------------------------------------
1 file changed, 6 insertions(+), 41 deletions(-)
diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index e2308119f8f0..7006f4caac2f 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -221,11 +221,6 @@ static LIST_HEAD(nvme_fc_lport_list);
static DEFINE_IDA(nvme_fc_local_port_cnt);
static DEFINE_IDA(nvme_fc_ctrl_cnt);
-static struct workqueue_struct *nvme_fc_wq;
-
-static bool nvme_fc_waiting_to_unload;
-static DECLARE_COMPLETION(nvme_fc_unload_proceed);
-
/*
* These items are short-term. They will eventually be moved into
* a generic FC class. See comments in module init.
@@ -255,8 +250,6 @@ nvme_fc_free_lport(struct kref *ref)
/* remove from transport list */
spin_lock_irqsave(&nvme_fc_lock, flags);
list_del(&lport->port_list);
- if (nvme_fc_waiting_to_unload && list_empty(&nvme_fc_lport_list))
- complete(&nvme_fc_unload_proceed);
spin_unlock_irqrestore(&nvme_fc_lock, flags);
ida_free(&nvme_fc_local_port_cnt, lport->localport.port_num);
@@ -3894,10 +3887,6 @@ static int __init nvme_fc_init_module(void)
{
int ret;
- nvme_fc_wq = alloc_workqueue("nvme_fc_wq", WQ_MEM_RECLAIM, 0);
- if (!nvme_fc_wq)
- return -ENOMEM;
-
/*
* NOTE:
* It is expected that in the future the kernel will combine
@@ -3915,7 +3904,7 @@ static int __init nvme_fc_init_module(void)
ret = class_register(&fc_class);
if (ret) {
pr_err("couldn't register class fc\n");
- goto out_destroy_wq;
+ return ret;
}
/*
@@ -3939,8 +3928,6 @@ static int __init nvme_fc_init_module(void)
device_destroy(&fc_class, MKDEV(0, 0));
out_destroy_class:
class_unregister(&fc_class);
-out_destroy_wq:
- destroy_workqueue(nvme_fc_wq);
return ret;
}
@@ -3960,45 +3947,23 @@ nvme_fc_delete_controllers(struct nvme_fc_rport *rport)
spin_unlock(&rport->lock);
}
-static void
-nvme_fc_cleanup_for_unload(void)
+static void __exit nvme_fc_exit_module(void)
{
struct nvme_fc_lport *lport;
struct nvme_fc_rport *rport;
-
- list_for_each_entry(lport, &nvme_fc_lport_list, port_list) {
- list_for_each_entry(rport, &lport->endp_list, endp_list) {
- nvme_fc_delete_controllers(rport);
- }
- }
-}
-
-static void __exit nvme_fc_exit_module(void)
-{
unsigned long flags;
- bool need_cleanup = false;
spin_lock_irqsave(&nvme_fc_lock, flags);
- nvme_fc_waiting_to_unload = true;
- if (!list_empty(&nvme_fc_lport_list)) {
- need_cleanup = true;
- nvme_fc_cleanup_for_unload();
- }
+ list_for_each_entry(lport, &nvme_fc_lport_list, port_list)
+ list_for_each_entry(rport, &lport->endp_list, endp_list)
+ nvme_fc_delete_controllers(rport);
spin_unlock_irqrestore(&nvme_fc_lock, flags);
- if (need_cleanup) {
- pr_info("%s: waiting for ctlr deletes\n", __func__);
- wait_for_completion(&nvme_fc_unload_proceed);
- pr_info("%s: ctrl deletes complete\n", __func__);
- }
+ flush_workqueue(nvme_delete_wq);
nvmf_unregister_transport(&nvme_fc_transport);
- ida_destroy(&nvme_fc_local_port_cnt);
- ida_destroy(&nvme_fc_ctrl_cnt);
-
device_destroy(&fc_class, MKDEV(0, 0));
class_unregister(&fc_class);
- destroy_workqueue(nvme_fc_wq);
}
module_init(nvme_fc_init_module);
--
2.43.0
next prev parent reply other threads:[~2024-01-31 8:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 8:51 [PATCH v5 00/12] enable nvmet-fc for blktests Daniel Wagner
2024-01-31 8:51 ` Daniel Wagner [this message]
2024-02-01 12:41 ` [PATCH v5 01/12] nvme-fc: do not wait in vain when unloading module Hannes Reinecke
2024-01-31 8:51 ` [PATCH v5 02/12] nvmet-fcloop: swap the list_add_tail arguments Daniel Wagner
2024-02-01 12:42 ` Hannes Reinecke
2024-01-31 8:51 ` [PATCH v5 03/12] nvmet-fc: release reference on target port Daniel Wagner
2024-01-31 8:51 ` [PATCH v5 04/12] nvmet-fc: defer cleanup using RCU properly Daniel Wagner
2024-02-01 12:43 ` Hannes Reinecke
2024-01-31 8:51 ` [PATCH v5 05/12] nvmet-fc: free queue and assoc directly Daniel Wagner
2024-01-31 8:51 ` [PATCH v5 06/12] nvmet-fc: hold reference on hostport match Daniel Wagner
2024-01-31 8:51 ` [PATCH v5 07/12] nvmet-fc: remove null hostport pointer check Daniel Wagner
2024-01-31 8:51 ` [PATCH v5 08/12] nvmet-fc: do not tack refs on tgtports from assoc Daniel Wagner
2024-01-31 8:51 ` [PATCH v5 09/12] nvmet-fc: abort command when there is no binding Daniel Wagner
2024-01-31 8:51 ` [PATCH v5 10/12] nvmet-fc: avoid deadlock on delete association path Daniel Wagner
2024-02-06 3:03 ` Hannes Reinecke
2024-01-31 8:51 ` [PATCH v5 11/12] nvmet-fc: take ref count on tgtport before delete assoc Daniel Wagner
2024-02-06 5:47 ` Hannes Reinecke
2024-01-31 8:51 ` [PATCH v5 12/12] nvmet-fc: use RCU list iterator for assoc_list Daniel Wagner
2024-01-31 17:31 ` Christoph Hellwig
2024-02-06 5:51 ` Hannes Reinecke
2024-02-06 19:22 ` Keith Busch
2024-02-12 10:31 ` Daniel Wagner
2024-02-01 0:28 ` [PATCH v5 00/12] enable nvmet-fc for blktests Keith Busch
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=20240131085112.21668-2-dwagner@suse.de \
--to=dwagner@suse.de \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=james.smart@broadcom.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox