linux-kernel - Re: [PATCH v9 9/9] scsi: ufs: Properly release resources if a task is aborted successfully

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1596447857.32283.24.camel@mtkswgap22>
Date:   Mon, 3 Aug 2020 17:44:17 +0800
From:   Stanley Chu <stanley.chu@...iatek.com>
To:     Can Guo <cang@...eaurora.org>
CC:     <asutoshd@...eaurora.org>, <nguyenb@...eaurora.org>,
        <hongwus@...eaurora.org>, <rnayak@...eaurora.org>,
        <linux-scsi@...r.kernel.org>, <kernel-team@...roid.com>,
        <saravanak@...gle.com>, <salyzyn@...gle.com>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        Avri Altman <avri.altman@....com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        "Bean Huo" <beanhuo@...ron.com>,
        Bart Van Assche <bvanassche@....org>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v9 9/9] scsi: ufs: Properly release resources if a task
 is aborted successfully

On Mon, 2020-08-03 at 02:04 -0700, Can Guo wrote:
> In current UFS task abort hook, namely ufshcd_abort(), if a task is
> aborted successfully, clock scaling busy time statistics is not updated
> and, most important, clk_gating.active_reqs is not decreased, which makes
> clk_gating.active_reqs stay above zero forever, thus clock gating would
> never happen. To fix it, instead of releasing resources "mannually", use
> the existing func __ufshcd_transfer_req_compl(). This can also eliminate
> racing of scsi_dma_unmap() from the real completion in IRQ handler path.
> 
> Signed-off-by: Can Guo <cang@...eaurora.org>
> CC: Stanley Chu <stanley.chu@...iatek.com>
> ---
>  drivers/scsi/ufs/ufshcd.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index d7d2758..9a48389 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -6635,11 +6635,8 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
>  		goto out;
>  	}
>  
> -	scsi_dma_unmap(cmd);
> -
>  	spin_lock_irqsave(host->host_lock, flags);
> -	ufshcd_outstanding_req_clear(hba, tag);
> -	hba->lrb[tag].cmd = NULL;
> +	__ufshcd_transfer_req_compl(hba, (1UL << tag));
>  	spin_unlock_irqrestore(host->host_lock, flags);
>  
>  out:

Reviewed-by: Stanley Chu <stanley.chu@...iatek.com>