From: Krishnamraju Eraparaju <krishna2@chelsio.com>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: linux-rdma@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: [PATCH v3] iwcm: don't hold the irq disabled lock on iw_rem_ref
Date: Tue, 10 Sep 2019 16:48:02 +0530 [thread overview]
Message-ID: <20190910111759.GA5472@chelsio.com> (raw)
In-Reply-To: <20190904212531.6488-1-sagi@grimberg.me>
On Wednesday, September 09/04/19, 2019 at 14:25:31 -0700, Sagi Grimberg wrote:
> This may be the final put on a qp and result in freeing
> resourcesand should not be done with interrupts disabled.
Hi Sagi,
Few things to consider in fixing this completely:
- there are some other places where iw_rem_ref() should be called
after spinlock critical section. eg: in cm_close_handler(),
iw_cm_connect(),...
- Any modifications to "cm_id_priv" should be done with in spinlock
critical section, modifying cm_id_priv->qp outside spinlocks, even
with atomic xchg(), might be error prone.
- the structure "siw_base_qp" is getting freed in siw_destroy_qp(),
but it should be done at the end of siw_free_qp().
I am about to finish writing a patch that cover all the above issues.
Will test it and submit here by EOD.
Regards,
Krishna.
>
> Produce the following warning:
> --
> [ 317.026048] WARNING: CPU: 1 PID: 443 at kernel/smp.c:425 smp_call_function_many+0xa0/0x260
> [ 317.026131] Call Trace:
> [ 317.026159] ? load_new_mm_cr3+0xe0/0xe0
> [ 317.026161] on_each_cpu+0x28/0x50
> [ 317.026183] __purge_vmap_area_lazy+0x72/0x150
> [ 317.026200] free_vmap_area_noflush+0x7a/0x90
> [ 317.026202] remove_vm_area+0x6f/0x80
> [ 317.026203] __vunmap+0x71/0x210
> [ 317.026211] siw_free_qp+0x8d/0x130 [siw]
> [ 317.026217] destroy_cm_id+0xc3/0x200 [iw_cm]
> [ 317.026222] rdma_destroy_id+0x224/0x2b0 [rdma_cm]
> [ 317.026226] nvme_rdma_reset_ctrl_work+0x2c/0x70 [nvme_rdma]
> [ 317.026235] process_one_work+0x1f4/0x3e0
> [ 317.026249] worker_thread+0x221/0x3e0
> [ 317.026252] ? process_one_work+0x3e0/0x3e0
> [ 317.026256] kthread+0x117/0x130
> [ 317.026264] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 317.026275] ret_from_fork+0x35/0x40
> --
>
> Fix this by exchanging the qp pointer early on and safely destroying
> it.
>
> Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
> ---
> Changes from v2:
> - store the qp locally so we don't need to unlock the cm_id_priv lock when
> destroying the qp
>
> Changes from v1:
> - don't release the lock before qp pointer is cleared.
>
> drivers/infiniband/core/iwcm.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/infiniband/core/iwcm.c b/drivers/infiniband/core/iwcm.c
> index 72141c5b7c95..c64707f68d22 100644
> --- a/drivers/infiniband/core/iwcm.c
> +++ b/drivers/infiniband/core/iwcm.c
> @@ -373,8 +373,10 @@ static void destroy_cm_id(struct iw_cm_id *cm_id)
> {
> struct iwcm_id_private *cm_id_priv;
> unsigned long flags;
> + struct ib_qp *qp;
>
> cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
> + qp = xchg(&cm_id_priv->qp, NULL);
> /*
> * Wait if we're currently in a connect or accept downcall. A
> * listening endpoint should never block here.
> @@ -401,7 +403,7 @@ static void destroy_cm_id(struct iw_cm_id *cm_id)
> cm_id_priv->state = IW_CM_STATE_DESTROYING;
> spin_unlock_irqrestore(&cm_id_priv->lock, flags);
> /* Abrupt close of the connection */
> - (void)iwcm_modify_qp_err(cm_id_priv->qp);
> + (void)iwcm_modify_qp_err(qp);
> spin_lock_irqsave(&cm_id_priv->lock, flags);
> break;
> case IW_CM_STATE_IDLE:
> @@ -426,11 +428,9 @@ static void destroy_cm_id(struct iw_cm_id *cm_id)
> BUG();
> break;
> }
> - if (cm_id_priv->qp) {
> - cm_id_priv->id.device->ops.iw_rem_ref(cm_id_priv->qp);
> - cm_id_priv->qp = NULL;
> - }
> spin_unlock_irqrestore(&cm_id_priv->lock, flags);
> + if (qp)
> + cm_id_priv->id.device->ops.iw_rem_ref(qp);
>
> if (cm_id->mapped) {
> iwpm_remove_mapinfo(&cm_id->local_addr, &cm_id->m_local_addr);
> --
> 2.17.1
>
next prev parent reply other threads:[~2019-09-10 11:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 21:25 [PATCH v3] iwcm: don't hold the irq disabled lock on iw_rem_ref Sagi Grimberg
2019-09-10 11:18 ` Krishnamraju Eraparaju [this message]
2019-09-10 16:53 ` Sagi Grimberg
2019-09-10 19:21 ` Krishnamraju Eraparaju
2019-09-11 9:38 ` Bernard Metzler
2019-09-11 14:42 ` Steve Wise
2019-09-11 15:58 ` Krishnamraju Eraparaju
2019-09-16 16:28 ` Jason Gunthorpe
2019-09-17 9:04 ` Bernard Metzler
2019-09-17 12:47 ` Krishnamraju Eraparaju
2019-09-17 13:40 ` Bernard Metzler
2019-09-17 17:20 ` Sagi Grimberg
2019-09-18 13:43 ` Krishnamraju Eraparaju
2019-09-21 18:35 ` Krishnamraju Eraparaju
2019-10-01 17:17 ` Krishnamraju Eraparaju
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=20190910111759.GA5472@chelsio.com \
--to=krishna2@chelsio.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=sagi@grimberg.me \
/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.