[PATCH v3 15/18] nvmet-fc: free pending reqs on tgtport unregister

Daniel Wagner posted 18 patches 9 months ago
There is a newer version of this series
[PATCH v3 15/18] nvmet-fc: free pending reqs on tgtport unregister
Posted by Daniel Wagner 9 months ago
When nvmet_fc_unregister_targetport is called by the LLDD, it's not
possible to communicate with the host, thus all pending request will not
be process. Thus explicitly free them.

Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Daniel Wagner <wagi@kernel.org>

nvmet-fc: merge with f200af94ac9d ("nvmet-fc: free pending reqs on tgtport unregister")
---
 drivers/nvme/target/fc.c | 46 +++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 39 insertions(+), 7 deletions(-)

diff --git a/drivers/nvme/target/fc.c b/drivers/nvme/target/fc.c
index b2f5934209f9952679dc1235fb7c927818930688..d10ddcb57c1b09d871152f0d9a48f93ec6dc8685 100644
--- a/drivers/nvme/target/fc.c
+++ b/drivers/nvme/target/fc.c
@@ -1591,6 +1591,44 @@ nvmet_fc_delete_ctrl(struct nvmet_ctrl *ctrl)
 	spin_unlock_irqrestore(&nvmet_fc_tgtlock, flags);
 }
 
+static void
+nvmet_fc_free_pending_reqs(struct nvmet_fc_tgtport *tgtport)
+{
+	struct nvmet_fc_ls_req_op *lsop;
+	struct nvmefc_ls_req *lsreq;
+	struct nvmet_fc_ls_iod *iod;
+	int i;
+
+	iod = tgtport->iod;
+	for (i = 0; i < NVMET_LS_CTX_COUNT; iod++, i++)
+		cancel_work(&iod->work);
+
+	/*
+	 * After this point the connection is lost and thus any pending
+	 * request can't be processed by the normal completion path. This
+	 * is likely a request from nvmet_fc_send_ls_req_async.
+	 */
+	for (;;) {
+		lsop = list_first_entry_or_null(&tgtport->ls_req_list,
+						struct nvmet_fc_ls_req_op,
+						lsreq_list);
+		if (!lsop)
+			break;
+
+		list_del(&lsop->lsreq_list);
+
+		if (!lsop->req_queued)
+			continue;
+
+		lsreq = &lsop->ls_req;
+		fc_dma_unmap_single(tgtport->dev, lsreq->rqstdma,
+				    (lsreq->rqstlen + lsreq->rsplen),
+				    DMA_BIDIRECTIONAL);
+		nvmet_fc_tgtport_put(tgtport);
+		kfree(lsop);
+	}
+}
+
 /**
  * nvmet_fc_unregister_targetport - transport entry point called by an
  *                              LLDD to deregister/remove a previously
@@ -1619,13 +1657,7 @@ nvmet_fc_unregister_targetport(struct nvmet_fc_target_port *target_port)
 
 	flush_workqueue(nvmet_wq);
 
-	/*
-	 * should terminate LS's as well. However, LS's will be generated
-	 * at the tail end of association termination, so they likely don't
-	 * exist yet. And even if they did, it's worthwhile to just let
-	 * them finish and targetport ref counting will clean things up.
-	 */
-
+	nvmet_fc_free_pending_reqs(tgtport);
 	nvmet_fc_tgtport_put(tgtport);
 
 	return 0;

-- 
2.48.1
Re: [PATCH v3 15/18] nvmet-fc: free pending reqs on tgtport unregister
Posted by Christoph Hellwig 9 months ago
On Tue, Mar 18, 2025 at 11:40:09AM +0100, Daniel Wagner wrote:
> nvmet-fc: merge with f200af94ac9d ("nvmet-fc: free pending reqs on tgtport unregister")

What is this supposed to mean?

> +	for (;;) {
> +		lsop = list_first_entry_or_null(&tgtport->ls_req_list,
> +						struct nvmet_fc_ls_req_op,
> +						lsreq_list);
> +		if (!lsop)
> +			break;

	while ((lsop = list_first_entry_or_null(&tgtport->ls_req_list,
			struct nvmet_fc_ls_req_op, lsreq_list))) {

> +
> +		list_del(&lsop->lsreq_list);

Another case where I'd really love to help the list_pop helper Linus
flamed me for :(
Re: [PATCH v3 15/18] nvmet-fc: free pending reqs on tgtport unregister
Posted by Daniel Wagner 8 months, 1 week ago
On Fri, Mar 21, 2025 at 07:19:03AM +0100, Christoph Hellwig wrote:
> On Tue, Mar 18, 2025 at 11:40:09AM +0100, Daniel Wagner wrote:
> > nvmet-fc: merge with f200af94ac9d ("nvmet-fc: free pending reqs on tgtport unregister")
> 
> What is this supposed to mean?

This a left over from my dev work.

> > +	for (;;) {
> > +		lsop = list_first_entry_or_null(&tgtport->ls_req_list,
> > +						struct nvmet_fc_ls_req_op,
> > +						lsreq_list);
> > +		if (!lsop)
> > +			break;
> 
> 	while ((lsop = list_first_entry_or_null(&tgtport->ls_req_list,
> 			struct nvmet_fc_ls_req_op, lsreq_list))) {
> 
> > +
> > +		list_del(&lsop->lsreq_list);
> 
> Another case where I'd really love to help the list_pop helper Linus
> flamed me for :(

Sure, will change these for(;;) loops into while() loops.

BTW, bcachefs seems to have it:

#define container_of_or_null(ptr, type, member)                         \
({                                                                      \
        typeof(ptr) _ptr = ptr;                                         \
        _ptr ? container_of(_ptr, type, member) : NULL;                 \
})

static inline struct list_head *list_pop(struct list_head *head)
{
        if (list_empty(head))
                return NULL;

        struct list_head *ret = head->next;
        list_del_init(ret);
        return ret;
}

#define list_pop_entry(head, type, member)              \
        container_of_or_null(list_pop(head), type, member)