All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Asutosh Das (asd)" <quic_asutoshd@quicinc.com>
To: Bart Van Assche <bvanassche@acm.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>, <linux-scsi@vger.kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	<dh0421.hwang@samsung.com>, Asutosh Das <asutoshd@codeaurora.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	Bean Huo <beanhuo@micron.com>, Avri Altman <avri.altman@wdc.com>,
	Jinyoung Choi <j-young.choi@samsung.com>
Subject: Re: [PATCH] scsi: ufs: Fix deadlocks between power management and error handler
Date: Sun, 18 Sep 2022 20:10:26 -0700	[thread overview]
Message-ID: <2be5b57f-f367-2e28-c317-e0daedcfb3a4@quicinc.com> (raw)
In-Reply-To: <20220916184220.867535-1-bvanassche@acm.org>

Hello Bart,

On 9/16/2022 11:42 AM, Bart Van Assche wrote:
> The following deadlocks have been observed on multiple test setups:
> 
> * ufshcd_wl_suspend() is waiting for blk_execute_rq() to complete while it
>    holds host_sem.
> * ufshcd_eh_host_reset_handler() invokes ufshcd_err_handler() and the
>    latter function tries to obtain host_sem.
> This is a deadlock because blk_execute_rq() can't execute SCSI commands
> while the host is in the SHOST_RECOVERY state and because the error
> handler cannot make progress either.
> 
> * ufshcd_wl_runtime_resume() is waiting for blk_execute_rq() to finish
>    while it holds host_sem.
> * ufshcd_eh_host_reset_handler() invokes ufshcd_err_handler() and the
>    latter function calls pm_runtime_resume().
> This is a deadlock because of the same reason as the previous scenario.
> 
> Fix both deadlocks by not obtaining host_sem from the power management
> code paths. Removing the host_sem locking from the power management code
> is safe because the ufshcd_err_handler() is already serialized against
> SCSI command execution.
> 

Say, there's a PWR_FATAL error in ufshcd_wl_suspend().
Wouldn't there be a scenario in which the suspend and error handler may 
run simultaneously?
Do you see issues when that happens? How about when shutdown runs 
simulataneously with error handler?

-asd

  reply	other threads:[~2022-09-19  3:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16 18:42 [PATCH] scsi: ufs: Fix deadlocks between power management and error handler Bart Van Assche
2022-09-19  3:10 ` Asutosh Das (asd) [this message]
2022-09-19 23:17   ` Bart Van Assche
2022-09-19 11:34 ` Adrian Hunter
2022-09-19 13:54   ` Bart Van Assche
2022-09-19 17:21     ` Adrian Hunter
2022-09-19 23:22       ` Bart Van Assche

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=2be5b57f-f367-2e28-c317-e0daedcfb3a4@quicinc.com \
    --to=quic_asutoshd@quicinc.com \
    --cc=adrian.hunter@intel.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=dh0421.hwang@samsung.com \
    --cc=j-young.choi@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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.