All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daejun Park <daejun7.park@samsung.com>
To: Bart Van Assche <bvanassche@acm.org>,
	Daejun Park <daejun7.park@samsung.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	Can Guo <cang@codeaurora.org>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Asutosh Das <asutoshd@codeaurora.org>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Vinayak Holikatti <vinholikatti@gmail.com>,
	VISHAK G <vishak.g@samsung.com>,
	Girish K S <girish.shivananjappa@linaro.org>,
	Santosh Yaraganavi <santoshsy@gmail.com>,
	"huobean@gmail.com" <huobean@gmail.com>
Subject: RE: [PATCH] scsi: ufs: Improve SCSI abort handling
Date: Fri, 05 Nov 2021 10:53:15 +0900	[thread overview]
Message-ID: <2038148563.21636078682214.JavaMail.epsvc@epcpadp4> (raw)
In-Reply-To: <cb0982d2-1124-a8ee-d129-e2e4975ef1c4@acm.org>

>On 11/4/21 4:39 PM, Daejun Park wrote:
>>> On 11/4/21 3:39 PM, Daejun Park wrote:
>>>> I found similar code in the ufshcd_err_handler(). I think the following
>>>> patch will required to fix another warning.
>>>>
>>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>>> index f5ba8f953b87..cce9abc6b879 100644
>>>> --- a/drivers/scsi/ufs/ufshcd.c
>>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>>> @@ -6190,6 +6190,7 @@ static void ufshcd_err_handler(struct work_struct *work)
>>>>                   }
>>>>                   dev_err(hba->dev, "Aborted tag %d / CDB %#02x\n", tag,
>>>>                           hba->lrb[tag].cmd ? hba->lrb[tag].cmd->cmnd[0] : -1);
>>>> +               hba->lrb[tag].cmd = NULL;
>>>>           }
>>>>
>>>>           /* Clear pending task management requests */
>>>
>>> Hmm ... since the error handler calls ufshcd_complete_requests(),
>>> shouldn't the completion function clear the 'cmd' member? I'm concerned
>>> that the above change would break the completion handler.
>> 
>> I missed that the error handler calls ufshcd_complete_requests(). Please
>> ignore my suggestion.
>> 
>> By the way, I give my reviewed-by tag.
>> 
>> Reviewed-by: Daejun Park <daejun7.park@samsung.com>
> 
>Thanks Daejun! However, your question made me wonder whether ufshcd_abort()
>should clear the 'tag' bit from hba->outstanding_reqs. Although the SCSI
>standard requires that a command that is aborted is not completed, the UFSHCI
>specification requires that writing into the UTRLCLR register clears the
>corresponding bit(s) in the UTRLDBR register. I think bit 'tag' will have to
>be cleared from hba->outstanding_reqs to prevent that the aborted request is
>completed while the SCSI core is resubmitting it.

My understanding is the completion of aborted request can be duplicated
because SCSI core will resubmit the request. Therefore the clearing of the 
bit can avoid duplicated completion of the request.

Thanks,
Daejun


  parent reply	other threads:[~2021-11-05  2:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 18:10 [PATCH] scsi: ufs: Improve SCSI abort handling Bart Van Assche
2021-11-04 22:20 ` Bean Huo
     [not found] ` <CGME20211104181111epcas2p2965ba25c905be783c39f098210cc4c61@epcms2p2>
2021-11-04 22:39   ` Daejun Park
2021-11-04 23:14     ` Bart Van Assche
     [not found]     ` <CGME20211104181111epcas2p2965ba25c905be783c39f098210cc4c61@epcms2p1>
2021-11-04 23:39       ` Daejun Park
2021-11-04 23:54         ` Bart Van Assche
     [not found]         ` <CGME20211104181111epcas2p2965ba25c905be783c39f098210cc4c61@epcms2p4>
2021-11-05  1:53           ` Daejun Park [this message]
2021-11-07  6:59 ` Stanley Chu
2021-11-09  4:03 ` Martin K. Petersen
2021-11-19  4:16 ` Martin K. Petersen
2021-12-14 16:35   ` James Bottomley
2021-12-14 17:37     ` Bart Van Assche
2021-12-14 17:43       ` James Bottomley
2021-12-14 17:45         ` 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=2038148563.21636078682214.JavaMail.epsvc@epcpadp4 \
    --to=daejun7.park@samsung.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=adrian.hunter@intel.com \
    --cc=asutoshd@codeaurora.org \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=girish.shivananjappa@linaro.org \
    --cc=huobean@gmail.com \
    --cc=jaegeuk@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=santoshsy@gmail.com \
    --cc=stanley.chu@mediatek.com \
    --cc=vinholikatti@gmail.com \
    --cc=vishak.g@samsung.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.