linux-kernel - Re: [PATCH v1 1/2] scsi: ufs: unify scsi_block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1577246863.13056.48.camel@mtkswgap22>
Date:   Wed, 25 Dec 2019 12:07:43 +0800
From:   Stanley Chu <stanley.chu@...iatek.com>
To:     Bart Van Assche <bvanassche@....org>
CC:     <linux-scsi@...r.kernel.org>, <martin.petersen@...cle.com>,
        <avri.altman@....com>, <alim.akhtar@...sung.com>,
        <pedrom.sousa@...opsys.com>, <jejb@...ux.ibm.com>,
        <matthias.bgg@...il.com>, <beanhuo@...ron.com>,
        <cang@...eaurora.org>, <linux-mediatek@...ts.infradead.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <kuohong.wang@...iatek.com>,
        <peter.wang@...iatek.com>, <chun-hung.wu@...iatek.com>,
        <andy.teng@...iatek.com>
Subject: Re: [PATCH v1 1/2] scsi: ufs: unify scsi_block_requests usage

Hi Bart,

> Hi Stanley,
> 
> From the SCSI core:
> 
> void scsi_block_requests(struct Scsi_Host *shost)
> {
> 	shost->host_self_blocked = 1;
> }
> 
> In other words, neither scsi_block_requests() nor
> ufshcd_scsi_block_requests() wait for ongoing ufshcd_queuecommand()
> calls to finish. Is it required to wait for these calls to finish before
> exceptions are handled? If not, can the scsi_block_requests() and
> scsi_unblock_requests() calls be left out? If it is required to wait for
> ongoing ufshcd_queuecommand() calls to finish then I think the
> scsi_block_requests() and scsi_unblock_requests() will have to be
> changed into something else.

ASFAIK, ufshcd_exception_event_handler() is not required to wait for
ongoing ufshcd_queuecommand() calls to finish.

The scsi_block_requests() call here is trying to increase successful
rate of requests sent by ufshcd_exception_event_handler() because
timeout may happen if device is too busy to handle those requests.
Blocking any future incoming requests can help.

As time goes by, actually current UFS driver allows more waiting time by
below changes for ufshcd_exception_event_handler(), and thus the
successful rate shall be raised much nowadays.

- Enlarge QUERY_REQ_TIMEOUT time from 100 ms to 1.5 seconds
- Allow retry if query requests are timed out

Therefore, the scsi_block_requests() call is actually a "helper" to help
ufshcd_exception_event_handler() successful. I think it could be better
kept to make UFS device recover its performance as soon as possible.

> 
> Thanks,
> 
> Bart.

Thanks,
Stanley