public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Asutosh Das <quic_asutoshd@quicinc.com>
To: Mason Zhang <mason.zhang@mediatek.com>
Cc: Alim Akhtar <alim.akhtar@samsung.com>,
	Avri Altman <avri.altman@wdc.com>,
	Bart Van Assche <bvanassche@acm.org>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Bean Huo <beanhuo@micron.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Jinyoung Choi <j-young.choi@samsung.com>,
	<linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	Peter Wang <peter.wang@mediatek.com>,
	Peng Zhou <peng.zhou@mediatek.com>, <wsd_upstream@mediatek.com>
Subject: Re: [PATCH v2 1/1] scsi: ufs: core: fix device management cmd timeout flow
Date: Mon, 5 Dec 2022 11:50:50 -0800	[thread overview]
Message-ID: <20221205195050.GA15334@asutoshd-linux1.qualcomm.com> (raw)
In-Reply-To: <20221205014202.2672-1-mason.zhang@mediatek.com>

On Mon, Dec 05 2022 at 17:53 -0800, Mason Zhang wrote:
>From: Mason Zhang <Mason.Zhang@mediatek.com>
>
>In ufs error handler flow, host will send device management cmd(NOP OUT)
>to device for recovery link. If cmd response timeout, and clear doorbell
>fail, ufshcd_wait_for_dev_cmd will do nothing and return,
>hba->dev_cmd.complete struct not set to null.
>
>In this time, if cmd has been responsed by device, then it will
>call complete() in __ufshcd_transfer_req_compl, because of complete
>struct is alloced in stack, then the KE will occur.
>
What is KE?

>Fix the following crash:
>  ipanic_die+0x24/0x38 [mrdump]
>  die+0x344/0x748
>  arm64_notify_die+0x44/0x104
>  do_debug_exception+0x104/0x1e0
>  el1_dbg+0x38/0x54
>  el1_sync_handler+0x40/0x88
>  el1_sync+0x8c/0x140
>  queued_spin_lock_slowpath+0x2e4/0x3c0
>  __ufshcd_transfer_req_compl+0x3b0/0x1164
>  ufshcd_trc_handler+0x15c/0x308
>  ufshcd_host_reset_and_restore+0x54/0x260
>  ufshcd_reset_and_restore+0x28c/0x57c
>  ufshcd_err_handler+0xeb8/0x1b6c
>  process_one_work+0x288/0x964
>  worker_thread+0x4bc/0xc7c
>  kthread+0x15c/0x264
>  ret_from_fork+0x10/0x30
>
>Signed-off-by: Mason Zhang <Mason.Zhang@mediatek.com>
>---
> drivers/ufs/core/ufshcd.c | 46 ++++++++++++++++++---------------------
> 1 file changed, 21 insertions(+), 25 deletions(-)
>
>diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
>index b1f59a5fe632..2b4934a562a6 100644
>--- a/drivers/ufs/core/ufshcd.c
>+++ b/drivers/ufs/core/ufshcd.c
>@@ -2979,35 +2979,31 @@ static int ufshcd_wait_for_dev_cmd(struct ufs_hba *hba,
> 		err = -ETIMEDOUT;
> 		dev_dbg(hba->dev, "%s: dev_cmd request timedout, tag %d\n",
> 			__func__, lrbp->task_tag);
>-		if (ufshcd_clear_cmds(hba, 1U << lrbp->task_tag) == 0) {
>+		if (ufshcd_clear_cmds(hba, 1U << lrbp->task_tag) == 0)
> 			/* successfully cleared the command, retry if needed */
> 			err = -EAGAIN;
>+		/*
>+		 * Since clearing the command succeeded we also need to
>+		 * clear the task tag bit from the outstanding_reqs
>+		 * variable.
>+		 */
Does this comment still hold true? Perhaps this needs to be updated?
Also, perhaps you missed Bart's comments in v1.
Also, please can you add a section for changes from v1 -> v2?

-asd

>+		spin_lock_irqsave(&hba->outstanding_lock, flags);
>+		pending = test_bit(lrbp->task_tag,
>+				   &hba->outstanding_reqs);
>+		if (pending) {
>+			hba->dev_cmd.complete = NULL;
>+			__clear_bit(lrbp->task_tag,
>+				    &hba->outstanding_reqs);
>+		}
>+		spin_unlock_irqrestore(&hba->outstanding_lock, flags);
>+
>+		if (!pending) {
> 			/*
>-			 * Since clearing the command succeeded we also need to
>-			 * clear the task tag bit from the outstanding_reqs
>-			 * variable.
>+			 * The completion handler ran while we tried to
>+			 * clear the command.
> 			 */
>-			spin_lock_irqsave(&hba->outstanding_lock, flags);
>-			pending = test_bit(lrbp->task_tag,
>-					   &hba->outstanding_reqs);
>-			if (pending) {
>-				hba->dev_cmd.complete = NULL;
>-				__clear_bit(lrbp->task_tag,
>-					    &hba->outstanding_reqs);
>-			}
>-			spin_unlock_irqrestore(&hba->outstanding_lock, flags);
>-
>-			if (!pending) {
>-				/*
>-				 * The completion handler ran while we tried to
>-				 * clear the command.
>-				 */
>-				time_left = 1;
>-				goto retry;
>-			}
>-		} else {
>-			dev_err(hba->dev, "%s: failed to clear tag %d\n",
>-				__func__, lrbp->task_tag);
>+			time_left = 1;
>+			goto retry;
> 		}
> 	}
>
>-- 
>2.18.0
>

  reply	other threads:[~2022-12-05 19:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05  1:42 [PATCH v2 1/1] scsi: ufs: core: fix device management cmd timeout flow Mason Zhang
2022-12-05 19:50 ` Asutosh Das [this message]
2022-12-07  9:24   ` Mason Zhang (章辉)

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=20221205195050.GA15334@asutoshd-linux1.qualcomm.com \
    --to=quic_asutoshd@quicinc.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=j-young.choi@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mason.zhang@mediatek.com \
    --cc=matthias.bgg@gmail.com \
    --cc=peng.zhou@mediatek.com \
    --cc=peter.wang@mediatek.com \
    --cc=stanley.chu@mediatek.com \
    --cc=wsd_upstream@mediatek.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