From: Mason Zhang <mason.zhang@mediatek.com>
To: 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>
Cc: <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>,
Mason Zhang <Mason.Zhang@mediatek.com>
Subject: [PATCH v2 1/1] scsi: ufs: core: fix device management cmd timeout flow
Date: Mon, 5 Dec 2022 09:42:03 +0800 [thread overview]
Message-ID: <20221205014202.2672-1-mason.zhang@mediatek.com> (raw)
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.
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.
+ */
+ 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
next reply other threads:[~2022-12-05 1:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-05 1:42 Mason Zhang [this message]
2022-12-05 19:50 ` [PATCH v2 1/1] scsi: ufs: core: fix device management cmd timeout flow Asutosh Das
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=20221205014202.2672-1-mason.zhang@mediatek.com \
--to=mason.zhang@mediatek.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=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