All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Saleem, Shiraz" <shiraz.saleem@intel.com>
To: Duoming Zhou <duoming@zju.edu.cn>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"jgg@ziepe.ca" <jgg@ziepe.ca>,
	"Ismail, Mustafa" <mustafa.ismail@intel.com>,
	"dan.carpenter@oracle.com" <dan.carpenter@oracle.com>
Subject: RE: [PATCH V4 09/11] drivers: infiniband: hw: Fix deadlock in irdma_cleanup_cm_core()
Date: Fri, 8 Apr 2022 18:17:46 +0000	[thread overview]
Message-ID: <MWHPR11MB00291BA918E17176BDB12578E9E99@MWHPR11MB0029.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220408030904.34145-1-duoming@zju.edu.cn>

> Subject: [PATCH V4 09/11] drivers: infiniband: hw: Fix deadlock in
> irdma_cleanup_cm_core()
> 
> There is a deadlock in irdma_cleanup_cm_core(), which is shown
> below:
> 
>    (Thread 1)              |      (Thread 2)
>                            | irdma_schedule_cm_timer()
> irdma_cleanup_cm_core()    |  add_timer()
>  spin_lock_irqsave() //(1) |  (wait a time)
>  ...                       | irdma_cm_timer_tick()
>  del_timer_sync()          |  spin_lock_irqsave() //(2)
>  (wait timer to stop)      |  ...
> 
> We hold cm_core->ht_lock in position (1) of thread 1 and use del_timer_sync() to
> wait timer to stop, but timer handler also need cm_core->ht_lock in position (2) of
> thread 2.
> As a result, irdma_cleanup_cm_core() will block forever.
> 
> This patch removes the check of timer_pending() in irdma_cleanup_cm_core(),
> because the del_timer_sync() function will just return directly if there isn't a pending
> timer. As a result, the lock is redundant, because there is no resource it could
> protect.
> 
> What`s more, we add mod_timer() in order to guarantee the timer in
> irdma_schedule_cm_timer() and irdma_cm_timer_tick() could be executed.
> 
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
> Changes in V4:
>   - Add mod_timer() in order to guarantee the timer could be executed.
> 
>  drivers/infiniband/hw/irdma/cm.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/irdma/cm.c b/drivers/infiniband/hw/irdma/cm.c
> index dedb3b7edd8..e4117b978bf 100644
> --- a/drivers/infiniband/hw/irdma/cm.c
> +++ b/drivers/infiniband/hw/irdma/cm.c
> @@ -1184,6 +1184,8 @@ int irdma_schedule_cm_timer(struct irdma_cm_node
> *cm_node,
>  	if (!was_timer_set) {
>  		cm_core->tcp_timer.expires = new_send->timetosend;
>  		add_timer(&cm_core->tcp_timer);
> +	} else {
> +		mod_timer(&cm_core->tcp_timer, new_send->timetosend);
>  	}

There is no need to do a mod_timer. In the timer pending case, the handler will fire when the current armed timer expires.

The handler batch process connection nodes of interest. And this connection node is marked for processing.


>  	spin_unlock_irqrestore(&cm_core->ht_lock, flags);
> 
> @@ -1367,6 +1369,8 @@ static void irdma_cm_timer_tick(struct timer_list *t)
>  		if (!timer_pending(&cm_core->tcp_timer)) {
>  			cm_core->tcp_timer.expires = nexttimeout;
>  			add_timer(&cm_core->tcp_timer);
> +		} else {
> +			mod_timer(&cm_core->tcp_timer, nexttimeout);

ditto. Please remove.

>  		}
>  		spin_unlock_irqrestore(&cm_core->ht_lock, flags);
>  	}
> @@ -3251,10 +3255,7 @@ void irdma_cleanup_cm_core(struct irdma_cm_core
> *cm_core)
>  	if (!cm_core)
>  		return;
> 
> -	spin_lock_irqsave(&cm_core->ht_lock, flags);
> -	if (timer_pending(&cm_core->tcp_timer))
> -		del_timer_sync(&cm_core->tcp_timer);
> -	spin_unlock_irqrestore(&cm_core->ht_lock, flags);
> +	del_timer_sync(&cm_core->tcp_timer);

This is fine.

Shiraz



      reply	other threads:[~2022-04-08 18:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08  3:09 [PATCH V4 09/11] drivers: infiniband: hw: Fix deadlock in irdma_cleanup_cm_core() Duoming Zhou
2022-04-08 18:17 ` Saleem, Shiraz [this message]

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=MWHPR11MB00291BA918E17176BDB12578E9E99@MWHPR11MB0029.namprd11.prod.outlook.com \
    --to=shiraz.saleem@intel.com \
    --cc=dan.carpenter@oracle.com \
    --cc=duoming@zju.edu.cn \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mustafa.ismail@intel.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 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.