linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>,
	linux-nvme@lists.infradead.org, Hannes Reinecke <hare@suse.de>,
	Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Subject: Re: [PATCH] nvmet-rdma: Release connections synchronously
Date: Thu, 18 May 2023 13:32:44 -0700	[thread overview]
Message-ID: <82c223c5-d6ba-d862-2d6e-31fbd3daa77d@acm.org> (raw)
In-Reply-To: <f2909fb6-26e4-f99f-c55b-1dcec577bb44@grimberg.me>

On 5/17/23 00:42, Sagi Grimberg wrote:
> On 5/11/23 18:03, Bart Van Assche wrote:
>> @@ -1582,11 +1566,6 @@ static int nvmet_rdma_queue_connect(struct 
>> rdma_cm_id *cm_id,
>>           goto put_device;
>>       }
>> -    if (queue->host_qid == 0) {
>> -        /* Let inflight controller teardown complete */
>> -        flush_workqueue(nvmet_wq);
>> -    }
>> -
>>       ret = nvmet_rdma_cm_accept(cm_id, queue, &event->param.conn);
>>       if (ret) {
>>           /*
> 
> You could have simply removed this hunk alone to make lockdep quiet on
> this, without the need to rework the async queue removal.
> 
> The flush here was added to prevent a reset/connect/disconnect storm
> causing the target to run out of resources (which we have seen reports
> about in the distant past). What prevents it now?
> 
> And you both reworked the teardown, and still removed the flush, I don't
> get why both are needed.

Hi Sagi,

My understanding is that the above flush_workqueue() call waits for 
prior release_work to complete. If the release_work instance is removed, 
I don't think that the above flush_workqueue() call is still necessary.

This patch prevents that the target runs out of resources by releasing 
connections synchronously instead of asynchronously.

Does the above answer your questions?

Bart.


  reply	other threads:[~2023-05-18 20:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 15:03 [PATCH] nvmet-rdma: Release connections synchronously Bart Van Assche
2023-05-14 10:38 ` Shinichiro Kawasaki
2023-05-15 17:29   ` Bart Van Assche
2023-05-29 11:49     ` Pawel Baldysiak
2023-05-17  7:42 ` Sagi Grimberg
2023-05-18 20:32   ` Bart Van Assche [this message]
2023-05-22  6:41     ` Sagi Grimberg
2023-05-22  7:07       ` Sagi Grimberg

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=82c223c5-d6ba-d862-2d6e-31fbd3daa77d@acm.org \
    --to=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=shinichiro.kawasaki@wdc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).