Re: [PATCH] ufs: host: Remove redundant dev_err()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Teardown order violation in ufs_qcom_remove() destroys the MSI domain before devres-managed IRQs are freed, leading to a potential Use-After-Free or panic.
--

--- Patch [1]: [PATCH] ufs: host: Remove redundant dev_err() ---
commit 2d60d33ee1768b4175522f72c450271bc5ddc6ae
Author: Pan Chuang <panchuang@vivo.com>

ufs: host: Remove redundant dev_err()

Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.

> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 291c434487648..7d690ea2fa674 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -2431,8 +2431,6 @@ static int ufs_qcom_config_esi(struct ufs_hba *hba)
>  		ret = devm_request_irq(hba->dev, qi[idx].irq, ufs_qcom_mcq_esi_handler,
>  				       IRQF_SHARED, "qcom-mcq-esi", qi + idx);
>  		if (ret) {
> -			dev_err(hba->dev, "%s: Failed to request IRQ for %d, err = %d\n",
> -				__func__, qi[idx].irq, ret);
>  			/* Free previously allocated IRQs */
>  			for (int j = 0; j < idx; j++)
>  				devm_free_irq(hba->dev, qi[j].irq, qi + j);

[Severity: High]
This is a pre-existing issue, but since devres-managed IRQs are used here, 
does ufs_qcom_remove() break teardown symmetry?

In ufs_qcom_remove(), the MSI domain is destroyed manually before
devres-managed IRQ handlers are released:

drivers/ufs/host/ufs-qcom.c:ufs_qcom_remove() {
    ...
    ufshcd_pltfrm_remove(pdev);
    if (host->esi_enabled)
        platform_device_msi_free_irqs_all(hba->dev);
    ...
}

When the device is unbound, platform_device_msi_free_irqs_all() destroys the
MSI IRQ domain and descriptors before devres runs.

When devm_irq_release() later calls free_irq(), it silently returns early
because the descriptor is already gone. This bypasses the critical
__synchronize_irq() and kthread_stop() cleanup logic.

Could this permanently leak the threaded IRQ handlers (struct irqaction
objects) and cause a use-after-free or kernel panic if a handler is
scheduled or running while the driver memory is freed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717035013.563791-1-panchuang@vivo.com?part=1