From: Jason Gunthorpe <jgg@ziepe.ca>
To: Jack Wang <jinpu.wang@cloud.ionos.com>
Cc: linux-rdma@vger.kernel.org, bvanassche@acm.org, leon@kernel.org,
dledford@redhat.com, danil.kipnis@cloud.ionos.com,
Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Subject: Re: [PATCHv2 for-next 02/19] RMDA/rtrs-srv: Occasionally flush ongoing session closing
Date: Tue, 12 Jan 2021 15:13:09 -0400 [thread overview]
Message-ID: <20210112191309.GC4605@ziepe.ca> (raw)
In-Reply-To: <20201217141915.56989-3-jinpu.wang@cloud.ionos.com>
On Thu, Dec 17, 2020 at 03:18:58PM +0100, Jack Wang wrote:
> If there are many establishments/teardowns, we need to make sure
> we do not consume too much system memory. Thus let on going
> session closing to finish before accepting new connection.
Then just limit it, why this scheme?
> In cma_ib_req_handler, the conn_id is newly created holding
> handler_mutex when call this function, and flush_workqueue
> wait for close_work to finish, in close_work rdma_destroy_id
> will be called, which will hold the handler_mutex, but they
> are mutex for different rdma_cm_id.
No, there are multiple handler locks held here, and the new one is
already marked nested, so isn't even the thing triggering lockdep.
The locking for CM is already bonkers, I don't want to see drivers
turning off lockdep. How are you sure that work queue doesn't become
(and won't ever in the future) become entangled with the listening
handler_mutex?
Jason
next prev parent reply other threads:[~2021-01-12 19:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 14:18 [PATCHv2 for-next 00/19] Misc update for rtrs Jack Wang
2020-12-17 14:18 ` [PATCHv2 for-next 01/19] RDMA/rtrs: Extend ibtrs_cq_qp_create Jack Wang
2020-12-17 14:18 ` [PATCHv2 for-next 02/19] RMDA/rtrs-srv: Occasionally flush ongoing session closing Jack Wang
2021-01-12 19:13 ` Jason Gunthorpe [this message]
2021-01-13 8:55 ` Jinpu Wang
2020-12-17 14:18 ` [PATCHv2 for-next 03/19] RDMA/rtrs-srv: Release lock before call into close_sess Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 04/19] RDMA/rtrs-srv: Use sysfs_remove_file_self for disconnect Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 05/19] RDMA/rtrs-clt: Set mininum limit when create QP Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 06/19] RDMA/rtrs-srv: Jump to dereg_mr label if allocate iu fails Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 07/19] RDMA/rtrs: Call kobject_put in the failure path Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 08/19] RDMA/rtrs-clt: Consolidate rtrs_clt_destroy_sysfs_root_{folder,files} Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 09/19] RDMA/rtrs-clt: Kill wait_for_inflight_permits Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 10/19] RDMA/rtrs-clt: Remove unnecessary 'goto out' Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 11/19] RDMA/rtrs-clt: Kill rtrs_clt_change_state Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 12/19] RDMA/rtrs-clt: Rename __rtrs_clt_change_state to rtrs_clt_change_state Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 13/19] RDMA/rtrs-srv: Fix missing wr_cqe Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 14/19] RDMA/rtrs-clt: Refactor the failure cases in alloc_clt Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 15/19] RDMA/rtrs: Do not signal for heatbeat Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 16/19] RDMA/rtrs-clt: Use bitmask to check sess->flags Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 17/19] RDMA/rtrs-srv: Do not signal REG_MR Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 18/19] RDMA/rtrs-srv: Init wr_cnt as 1 Jack Wang
2020-12-17 14:19 ` [PATCHv2 for-next 19/19] RDMA/rtrs: Fix KASAN: stack-out-of-bounds bug Jack Wang
2021-01-11 7:04 ` [PATCHv2 for-next 00/19] Misc update for rtrs Jinpu Wang
2021-01-15 19:48 ` Jason Gunthorpe
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=20210112191309.GC4605@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=bvanassche@acm.org \
--cc=danil.kipnis@cloud.ionos.com \
--cc=dledford@redhat.com \
--cc=guoqing.jiang@cloud.ionos.com \
--cc=jinpu.wang@cloud.ionos.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.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.