linux-kernel - Re: [PATCH] scsi: ufs: core: Do not hold any lock in ufshcd_hba

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] [day] [month] [year] [list]

Message-ID: <87f1bb6b-6a8e-4bfd-8c1f-d63c857a176e@acm.org>
Date: Mon, 25 Nov 2024 15:07:18 -0800
From: Bart Van Assche <bvanassche@....org>
To: Avri Altman <avri.altman@....com>,
 "Martin K . Petersen" <martin.petersen@...cle.com>
Cc: linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: ufs: core: Do not hold any lock in ufshcd_hba_stop

On 11/24/24 3:07 AM, Avri Altman wrote:
> This change is motivated by Bart's suggestion in [1], which enables to
> further reduce the scsi host lock usage in the ufs driver. The reason
> why it make sense, because although the legacy interrupt is disabled by
> some but not all ufshcd_hba_stop() callers, it is safe to nest
> disable_irq() calls as it checks the irq depth.
> 
> [1] https://lore.kernel.org/linux-scsi/c58e4fce-0a74-4469-ad16-f1edbd670728@acm.org/
> 
> Suggested-by: Bart Van Assche <bvanassche@....org>
> Signed-off-by: Avri Altman <avri.altman@....com>
> ---
>   drivers/ufs/core/ufshcd.c | 9 ++-------
>   1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index acc3607bbd9c..09a5ff49da5a 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -4811,16 +4811,11 @@ EXPORT_SYMBOL_GPL(ufshcd_make_hba_operational);
>    */
>   void ufshcd_hba_stop(struct ufs_hba *hba)
>   {
> -	unsigned long flags;
>   	int err;
>   
> -	/*
> -	 * Obtain the host lock to prevent that the controller is disabled
> -	 * while the UFS interrupt handler is active on another CPU.
> -	 */
> -	spin_lock_irqsave(hba->host->host_lock, flags);
> +	ufshcd_disable_irq(hba);
>   	ufshcd_writel(hba, CONTROLLER_DISABLE,  REG_CONTROLLER_ENABLE);
> -	spin_unlock_irqrestore(hba->host->host_lock, flags);
> +	ufshcd_enable_irq(hba);
>   
>   	err = ufshcd_wait_for_register(hba, REG_CONTROLLER_ENABLE,
>   					CONTROLLER_ENABLE, CONTROLLER_DISABLE,

Shouldn't the ufshcd_enable_irq() call be moved below the 
ufshcd_wait_for_register() call? Otherwise a race condition could cause
the interrupt handler to be triggered while the controller is being
disabled.

Thanks,

Bart.