Re: [PATCH] scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context

[Bart Van Assche <bvanassche@acm.org>]

On 6/16/26 2:06 AM, Can Guo wrote:
> diff --git a/drivers/ufs/core/ufs-txeq.c b/drivers/ufs/core/ufs-txeq.c
> index 4b264adfdf49..3a2fb5329d27 100644
> --- a/drivers/ufs/core/ufs-txeq.c
> +++ b/drivers/ufs/core/ufs-txeq.c
> @@ -1059,7 +1059,7 @@ static int __ufshcd_tx_eqtr(struct ufs_hba *hba,
>   			    struct ufs_pa_layer_attr *pwr_mode)
>   {
>   	struct ufshcd_tx_eqtr_data *eqtr_data  __free(kfree) =
> -		kzalloc(sizeof(*eqtr_data), GFP_KERNEL);
> +		kzalloc(sizeof(*eqtr_data), GFP_NOIO);
>   	struct tx_eqtr_iter h_iter = {};
>   	struct tx_eqtr_iter d_iter = {};
>   	u32 gear = pwr_mode->gear_tx;
> @@ -1217,7 +1217,7 @@ static int ufshcd_tx_eqtr(struct ufs_hba *hba,
>   	if (!params->eqtr_record) {
>   		params->eqtr_record = devm_kzalloc(hba->dev,
>   						   sizeof(*params->eqtr_record),
> -						   GFP_KERNEL);
> +						   GFP_NOIO);
>   		if (!params->eqtr_record)
>   			return -ENOMEM;
>   	}
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index c084ccc72523..e7f104987c6a 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -2760,7 +2760,7 @@ static int ufs_qcom_get_rx_fom(struct ufs_hba *hba,
>   			       struct tx_eqtr_iter *d_iter)
>   {
>   	struct ufshcd_tx_eq_params *params __free(kfree) =
> -		kzalloc(sizeof(*params), GFP_KERNEL);
> +		kzalloc(sizeof(*params), GFP_NOIO);
>   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>   	struct ufs_pa_layer_attr old_pwr_info;
>   	u32 fom[PA_MAXDATALANES] = { 0 };

Modifying individual memory allocation calls is error prone. The next
person who modifies this code may not be aware of this conversation and
might reintroduce a GFP_KERNEL allocation in the TX equalization code.

Please use memalloc_noio_save() and memalloc_noio_restore() instead of
changing GFP_KERNEL into GFP_NOIO. Additionally, please add a comment
above the memalloc_noio_save() call that explains why it is necessary.
See also https://docs.kernel.org/core-api/gfp_mask-from-fs-io.html.

Thanks,

Bart.