From: "Peter Wang (王信友)" <peter.wang@mediatek.com>
To: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"Jiajie Hao (郝加节)" <jiajie.hao@mediatek.com>,
"CC Chou (周志杰)" <cc.chou@mediatek.com>,
"Eddie Huang (黃智傑)" <eddie.huang@mediatek.com>,
"Alice Chao (趙珮均)" <Alice.Chao@mediatek.com>,
"Ed Tsai (蔡宗軒)" <Ed.Tsai@mediatek.com>,
wsd_upstream <wsd_upstream@mediatek.com>,
"quic_nguyenb@quicinc.com" <quic_nguyenb@quicinc.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"Lin Gui (桂林)" <Lin.Gui@mediatek.com>,
"Chun-Hung Wu (巫駿宏)" <Chun-hung.Wu@mediatek.com>,
"Tun-yu Yu (游敦聿)" <Tun-yu.Yu@mediatek.com>,
"Chaotian Jing (井朝天)" <Chaotian.Jing@mediatek.com>,
"Powen Kao (高伯文)" <Powen.Kao@mediatek.com>,
"Naomi Chu (朱詠田)" <Naomi.Chu@mediatek.com>,
"Qilin Tan (谭麒麟)" <Qilin.Tan@mediatek.com>
Subject: Re: [PATCH v2 2/2] ufs: core: requeue MCQ abort request
Date: Mon, 9 Sep 2024 03:40:47 +0000 [thread overview]
Message-ID: <e31f180a8e78efbbab1a9a4cb5c83478f2bf4516.camel@mediatek.com> (raw)
In-Reply-To: <b31bf24f-588e-43e5-b71f-b4e9edd1b60a@acm.org>
On Thu, 2024-09-05 at 14:16 -0700, Bart Van Assche wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On 9/1/24 7:18 PM, peter.wang@mediatek.com wrote:
> > diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-
> mcq.c
> > index afd9541f4bd8..abdc55a8b960 100644
> > --- a/drivers/ufs/core/ufs-mcq.c
> > +++ b/drivers/ufs/core/ufs-mcq.c
> > @@ -642,6 +642,7 @@ static bool ufshcd_mcq_sqe_search(struct
> ufs_hba *hba,
> > match = le64_to_cpu(utrd->command_desc_base_addr) & CQE_UCD_BA;
> > if (addr == match) {
> > ufshcd_mcq_nullify_sqe(utrd);
> > +lrbp->host_initiate_abort = true;
> > ret = true;
> > goto out;
> > }
>
> I think this is wrong. The above code is only executed if the SCSI
> core
> decides to abort a SCSI command. It is up to the SCSI core to decide
> whether or not to retry an aborted command.
>
Hi Bart,
This is eh_abort_handler call flow for scsi err handler.
If abort is trigger because error, should't we do retry?
Anyway, I think this case could not happen because if scsi
timeout happen (30s), host hw should not keep cmd in SQ such
a long time. But once it happen, ufshcd_mcq_sqe_search return
true and scsi got eh_abort_handler fail. So, I think in this
case, notify scsi retry this command is properly.
> > -/* Release cmd in MCQ mode if abort succeeds */
> > -if (hba->mcq_enabled && (*ret == 0)) {
> > -hwq = ufshcd_mcq_req_to_hwq(hba, scsi_cmd_to_rq(lrbp->cmd));
> > -if (!hwq)
> > -return 0;
> > -spin_lock_irqsave(&hwq->cq_lock, flags);
> > -if (ufshcd_cmd_inflight(lrbp->cmd))
> > -ufshcd_release_scsi_cmd(hba, lrbp);
> > -spin_unlock_irqrestore(&hwq->cq_lock, flags);
> > -}
> > +/* Host will post to CQ with OCS_ABORTED after SQ cleanup */
> > +if (hba->mcq_enabled && (*ret == 0))
> > +lrbp->host_initiate_abort = true;
>
> I think this code is racy because the UFS host controller may have
> posted a completion before the "lrbp->host_initiate_abort = true"
> assignment is executed.
>
Yes, I should add this code before ufshcd_clear_cmd, thanks.
> > + * @host_initiate_abort: Abort flag initiated by host
>
> What is "Abort flag"? Please consider renaming "host_initiate_abort"
> into "abort_initiated_by_err_handler" since I think that aborted
> commands should only be retried if these have been aborted by
> ufshcd_err_handler().
>
Okay, but abort_initiated_by_err maybe better because aborted by
ufshcd_err_handler or scsi err handler could happen.
What do you think?
> Thanks,
>
> Bart.
prev parent reply other threads:[~2024-09-09 3:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 2:18 [PATCH v2 0/2] fix MCQ abort defect peter.wang
2024-09-02 2:18 ` [PATCH v2 1/2] ufs: core: fix the issue of ICU failure peter.wang
2024-09-03 12:56 ` Peter Wang (王信友)
2024-09-05 21:06 ` Bart Van Assche
2024-09-09 3:38 ` Peter Wang (王信友)
2024-09-06 20:39 ` Bao D. Nguyen
2024-09-09 3:41 ` Peter Wang (王信友)
2024-09-02 2:18 ` [PATCH v2 2/2] ufs: core: requeue MCQ abort request peter.wang
2024-09-05 21:16 ` Bart Van Assche
2024-09-09 3:40 ` Peter Wang (王信友) [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=e31f180a8e78efbbab1a9a4cb5c83478f2bf4516.camel@mediatek.com \
--to=peter.wang@mediatek.com \
--cc=Alice.Chao@mediatek.com \
--cc=Chaotian.Jing@mediatek.com \
--cc=Chun-hung.Wu@mediatek.com \
--cc=Ed.Tsai@mediatek.com \
--cc=Lin.Gui@mediatek.com \
--cc=Naomi.Chu@mediatek.com \
--cc=Powen.Kao@mediatek.com \
--cc=Qilin.Tan@mediatek.com \
--cc=Tun-yu.Yu@mediatek.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=bvanassche@acm.org \
--cc=cc.chou@mediatek.com \
--cc=eddie.huang@mediatek.com \
--cc=jejb@linux.ibm.com \
--cc=jiajie.hao@mediatek.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=quic_nguyenb@quicinc.com \
--cc=stable@vger.kernel.org \
--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