From: Stanley Chu <stanley.chu@mediatek.com>
To: Avri Altman <Avri.Altman@wdc.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"marc.w.gonzalez@free.fr" <marc.w.gonzalez@free.fr>,
"andy.teng@mediatek.com" <andy.teng@mediatek.com>,
"chun-hung.wu@mediatek.com" <chun-hung.wu@mediatek.com>,
"kuohong.wang@mediatek.com" <kuohong.wang@mediatek.com>,
"evgreen@chromium.org" <evgreen@chromium.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"peter.wang@mediatek.com" <peter.wang@mediatek.com>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"pedrom.sousa@synopsys.com" <pedrom.sousa@synopsys.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"beanhuo@micron.com" <beanhuo@micron.com>
Subject: RE: [PATCH v1 0/2] scsi: ufs: Fix broken hba->outstanding_tasks
Date: Wed, 24 Jul 2019 13:08:24 +0800 [thread overview]
Message-ID: <1563944904.7235.8.camel@mtkswgap22> (raw)
In-Reply-To: <SN6PR04MB49256F66F259185F3876CCABFCC40@SN6PR04MB4925.namprd04.prod.outlook.com>
Hi Avri,
On Mon, 2019-07-22 at 06:10 +0000, Avri Altman wrote:
> >
> > >
> > > Hi,
> > >
> > > >
> > > > Currently bits in hba->outstanding_tasks are cleared only after their
> > > > corresponding task management commands are successfully done by
> > > > __ufshcd_issue_tm_cmd().
> > > >
> > > > If timeout happens in a task management command, its corresponding
> > > > bit in hba->outstanding_tasks will not be cleared until next task
> > > > management command with the same tag used successfully finishes.‧
> > > ufshcd_clear_tm_cmd is also called as part of ufshcd_err_handler.
> > > Does this change something in your assumptions?
> > And BTW there is a specific __clear_bit in __ufshcd_issue_tm_cmd() in case
> > of a TO.
>
> Gave it another look -
> If indeed this bit isn't cleared as part of the error flow that the timeout triggers,
> I think you should relate to ufshcd_clear_tm_cmd specifically in your commit log -
> Because this is the obvious place where the bit cleanup should take place.
>
> Also the fix should be much more intuitive IMO -
> Today we do __clear_bit() on success, ufshcd_clear_tm_cmd() on error,
> And also ufshcd_put_tm_slot() either way?
>
> Maybe you can choose a single place to clear it, without any additional code?
ufshcd_clear_tm_cmd() is similar to ufshcd_clear_cmd() which tries to
write timed-out bit in "clear register". They do not clean bits in both
outstanding masks.
Another reason to not to do outstanding bits cleanup in
ufshcd_clear_tm_cmd() is: if host is unable to clear TM command by
setting "clear register", the TM command may be still "outstanding" in
the device. In this case, it may be better to do cleanup after reset is
done. Cleanup includes bits in hba->outstanding_tasks and
hba->tm_slots_in_use which is possibly cleaned too early by
ufshcd_put_tm_slot() if command is timed-out now.
Referring to error handling flow of hba->outstanding_reqs, all timed-out
bits will be cleaned by ufshcd_reset_and_restore() =>
ufshcd_transfer_req_compl() after reset is done. Similar handling for
hba->outstanding_tasks could be applied, i.e., do cleanup by
ufshcd_reset_and_restore() => ufshcd_tmc_handler().
The next thing is what you suggested: How to make the fix more
intuitive. Patchset v2 will be uploaded for review: It tries to
"re-factor" cleanup jobs first, and then add fixed flow to make the
whole patch more readable.
One more thing, above description and flow is done through UFSHCD SCSI
error handling routines registered with SCSI Midlayer. For TM command
timeout happening in bsg path without error handling triggered by SCSI
layer, we may need to consider to handle those tasks in future patches.
>
> Thanks,
> Avri
Thanks,
Stanley
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-24 5:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 4:44 [PATCH v1 0/2] scsi: ufs: Fix broken hba->outstanding_tasks Stanley Chu
2019-07-12 4:44 ` [PATCH v1 1/2] scsi: ufs: Make new function for clearing outstanding task bits Stanley Chu
2019-07-12 4:44 ` [PATCH v1 2/2] scsi: ufs: Fix broken hba->outstanding_tasks Stanley Chu
2019-07-18 5:21 ` [PATCH v1 0/2] " Stanley Chu
2019-07-21 12:46 ` Avri Altman
2019-07-21 12:52 ` Avri Altman
2019-07-22 6:10 ` Avri Altman
2019-07-24 5:08 ` Stanley Chu [this message]
2019-07-24 7:09 ` Avri Altman
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=1563944904.7235.8.camel@mtkswgap22 \
--to=stanley.chu@mediatek.com \
--cc=Avri.Altman@wdc.com \
--cc=alim.akhtar@samsung.com \
--cc=andy.teng@mediatek.com \
--cc=beanhuo@micron.com \
--cc=chun-hung.wu@mediatek.com \
--cc=evgreen@chromium.org \
--cc=kuohong.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=marc.w.gonzalez@free.fr \
--cc=martin.petersen@oracle.com \
--cc=matthias.bgg@gmail.com \
--cc=pedrom.sousa@synopsys.com \
--cc=peter.wang@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;
as well as URLs for NNTP newsgroup(s).