linux-kernel - Re: [PATCH] ufs: core: fix bus timeout in ufshcd_wl

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: <b2fbe277-2819-4af4-9b36-b7407618cbf6@acm.org>
Date: Tue, 13 Aug 2024 18:41:29 -0700
From: Bart Van Assche <bvanassche@....org>
To: ZhangHui <zhanghui31@...omi.com>, James.Bottomley@...senPartnership.com,
 martin.petersen@...cle.com
Cc: alim.akhtar@...sung.com, avri.altman@....co, peter.wang@...iatek.com,
 manivannan.sadhasivam@...aro.org, huangjianan@...omi.com,
 linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ufs: core: fix bus timeout in ufshcd_wl_resume flow

On 8/13/24 6:47 AM, ZhangHui wrote:
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 5e3c67e96956..e5e3e0277d43 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -3291,6 +3291,8 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
>   	struct ufshcd_lrb *lrbp = &hba->lrb[tag];
>   	int err;
>   
> +	if (hba->ufshcd_reg_state == UFSHCD_REG_RESET)
> +		return -EBUSY;
>   	/* Protects use of hba->reserved_slot. */
>   	lockdep_assert_held(&hba->dev_cmd.lock);

Does this change make ufshcd_exec_dev_cmd() unpredictable - it succeeds
if the controller is in the normal state and fails if error recovery
is ongoing? If so, which code paths does this affect and/or break?

Additionally, I think the above check is racy. hba->ufshcd_reg_state may
change after the above code checked it and before ufshcd_exec_dev_cmd()
has finished. Wouldn't it be better to make code that shouldn't be
executed while the error handler is ongoing wait until error handling
has finished?

Thanks,

Bart.