All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume()
@ 2026-06-03 10:24 Wentao Liang
  2026-06-03 10:39 ` sashiko-bot
  2026-06-04 10:03 ` Niklas Cassel
  0 siblings, 2 replies; 4+ messages in thread
From: Wentao Liang @ 2026-06-03 10:24 UTC (permalink / raw)
  To: dlemoal, cassel; +Cc: linux-ide, linux-kernel, Wentao Liang, stable

When brcm_ahci_resume() succeeds with reset_control_reset(), any
subsequent failure in ahci_platform_enable_clks(),
ahci_platform_enable_regulators(), ahci_platform_enable_phys(),
or ahci_platform_resume_host() leaves the shared reset line's
triggered_count incremented by one. On the next attempt to reset
the hardware, atomic_inc_return() sees a count greater than one
and the reset is silently skipped, potentially causing data
corruption or device malfunction.

Add a reset_control_rearm() call in the common error path after
brcm_sata_phys_disable() and ahci_platform_disable_regulators()
to properly balance the triggered_count, matching what the probe
error path already does.

Fixes: c0cdf2ac4b5b ("ata: ahci_brcm: Fix AHCI resources management")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
 drivers/ata/ahci_brcm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
index 29be74fedcf0..38c63d73d210 100644
--- a/drivers/ata/ahci_brcm.c
+++ b/drivers/ata/ahci_brcm.c
@@ -415,6 +415,7 @@ static int __maybe_unused brcm_ahci_resume(struct device *dev)
 out_disable_phys:
 	brcm_sata_phys_disable(priv);
 	ahci_platform_disable_regulators(hpriv);
+	reset_control_rearm(priv->rcdev_rescal);
 out_disable_clks:
 	ahci_platform_disable_clks(hpriv);
 	return ret;
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume()
  2026-06-03 10:24 [PATCH] ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume() Wentao Liang
@ 2026-06-03 10:39 ` sashiko-bot
  2026-06-04 10:03 ` Niklas Cassel
  1 sibling, 0 replies; 4+ messages in thread
From: sashiko-bot @ 2026-06-03 10:39 UTC (permalink / raw)
  To: Wentao Liang; +Cc: dlemoal, cassel, linux-ide

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

Pre-existing issues:
- [High] The patch fails to fix the `reset_control_rearm()` leak for the `ahci_platform_enable_clks()` and `ahci_platform_enable_regulators()` error paths in `brcm_ahci_resume()`, explicitly contradicting its commit message.
- [High] Error paths in `brcm_ahci_resume()` fail to call `reset_control_assert(priv->rcdev_ahci)`.
- [High] Missing `reset_control_rearm(priv->rcdev_rescal)` in `brcm_ahci_probe()` if `reset_control_deassert(priv->rcdev_ahci)` fails.
- [High] `brcm_ahci_remove()` fails to call `reset_control_rearm()` and `reset_control_assert()`, leading to permanent resource leaks on module unload.
--

commit 075a88f5a8b3bff5899fc69114efba28b24bf30d
Author: Wentao Liang <vulab@iscas.ac.cn>
Subject: ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume()

This patch attempts to fix a reset refcount leak in the error path of
brcm_ahci_resume(). It adds a call to reset_control_rearm() to balance
the triggered_count when subsequent initialization steps fail after a
successful reset.

> When brcm_ahci_resume() succeeds with reset_control_reset(), any
> subsequent failure in ahci_platform_enable_clks(),
> ahci_platform_enable_regulators(), ahci_platform_enable_phys(),
> or ahci_platform_resume_host() leaves the shared reset line's
> triggered_count incremented by one.

[ ... ]

> Add a reset_control_rearm() call in the common error path after
> brcm_sata_phys_disable() and ahci_platform_disable_regulators()
> to properly balance the triggered_count, matching what the probe
> error path already does.

[Severity: High]
Does this patch actually resolve the leak for all the functions mentioned
in the commit message?

Looking at the code in brcm_ahci_resume(), if ahci_platform_enable_clks()
fails, it returns directly:

	ret = ahci_platform_enable_clks(hpriv);
	if (ret)
		return ret;

And if ahci_platform_enable_regulators() fails, it jumps to out_disable_clks:

	ret = ahci_platform_enable_regulators(hpriv);
	if (ret)
		goto out_disable_clks;

Both of these error paths bypass the newly added reset_control_rearm() call,
leaving the triggered_count leak unfixed for these conditions.

> diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
> index 29be74fedcf01..38c63d73d210b 100644
> --- a/drivers/ata/ahci_brcm.c
> +++ b/drivers/ata/ahci_brcm.c
> @@ -415,6 +415,7 @@ static int __maybe_unused brcm_ahci_resume(struct device *dev)
>  out_disable_phys:
>  	brcm_sata_phys_disable(priv);
>  	ahci_platform_disable_regulators(hpriv);
> +	reset_control_rearm(priv->rcdev_rescal);
>  out_disable_clks:
>  	ahci_platform_disable_clks(hpriv);
>  	return ret;

[Severity: High]
This isn't a bug introduced by this patch, but does brcm_ahci_resume() also
leak the assertion state of rcdev_ahci on error?

Earlier in brcm_ahci_resume(), the reset control is deasserted:

	ret = reset_control_deassert(priv->rcdev_ahci);
	if (ret)
		return ret;

However, the entire error handling block at the end of the function (shown in
the diff above) lacks a corresponding call to
reset_control_assert(priv->rcdev_ahci), which leaves the line permanently
deasserted if a failure occurs later in the resume process.

[Severity: High]
This is a pre-existing issue, but is there a similar missing rearm in
brcm_ahci_probe()?

If reset_control_deassert() fails in the probe function, it returns directly:

	ret = reset_control_reset(priv->rcdev_rescal);
	if (ret)
		return ret;
	ret = reset_control_deassert(priv->rcdev_ahci);
	if (ret)
		return ret;

This skips jumping to the out_reset label, leaking the previously incremented
triggered_count of rcdev_rescal. Could this be updated to properly jump to
the cleanup path?

[Severity: High]
This is a pre-existing issue, but does module removal permanently leak these
reset resources?

When the module is unloaded, brcm_ahci_remove() only disables the PHYs and
removes the platform device:

drivers/ata/ahci_brcm.c:brcm_ahci_remove()
{
	struct ata_host *host = dev_get_drvdata(&pdev->dev);
	struct ahci_host_priv *hpriv = host->private_data;
	struct brcm_ahci_priv *priv = hpriv->plat_data;

	brcm_sata_phys_disable(priv);

	ata_platform_remove_one(pdev);
}

Should this function also call reset_control_rearm() and
reset_control_assert() to balance the operations from probe? Without them,
the triggered_count leaks permanently because devm cleanup only calls
reset_control_put().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603102420.3735032-1-vulab@iscas.ac.cn?part=1

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume()
  2026-06-03 10:24 [PATCH] ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume() Wentao Liang
  2026-06-03 10:39 ` sashiko-bot
@ 2026-06-04 10:03 ` Niklas Cassel
  2026-06-04 11:31   ` Niklas Cassel
  1 sibling, 1 reply; 4+ messages in thread
From: Niklas Cassel @ 2026-06-04 10:03 UTC (permalink / raw)
  To: Wentao Liang, Florian Fainelli; +Cc: dlemoal, linux-ide, linux-kernel, stable

On Wed, Jun 03, 2026 at 10:24:20AM +0000, Wentao Liang wrote:
> When brcm_ahci_resume() succeeds with reset_control_reset(), any
> subsequent failure in ahci_platform_enable_clks(),
> ahci_platform_enable_regulators(), ahci_platform_enable_phys(),
> or ahci_platform_resume_host() leaves the shared reset line's
> triggered_count incremented by one. On the next attempt to reset
> the hardware, atomic_inc_return() sees a count greater than one
> and the reset is silently skipped, potentially causing data
> corruption or device malfunction.
> 
> Add a reset_control_rearm() call in the common error path after
> brcm_sata_phys_disable() and ahci_platform_disable_regulators()
> to properly balance the triggered_count, matching what the probe
> error path already does.
> 
> Fixes: c0cdf2ac4b5b ("ata: ahci_brcm: Fix AHCI resources management")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
>  drivers/ata/ahci_brcm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
> index 29be74fedcf0..38c63d73d210 100644
> --- a/drivers/ata/ahci_brcm.c
> +++ b/drivers/ata/ahci_brcm.c
> @@ -415,6 +415,7 @@ static int __maybe_unused brcm_ahci_resume(struct device *dev)
>  out_disable_phys:
>  	brcm_sata_phys_disable(priv);
>  	ahci_platform_disable_regulators(hpriv);
> +	reset_control_rearm(priv->rcdev_rescal);
>  out_disable_clks:
>  	ahci_platform_disable_clks(hpriv);
>  	return ret;

When writing a fix that has a Fixes-tag, please CC the author of the offending
commit. Note that if you use ./scripts/get_maintainer.pn on a a patch, it will
automatically include the author of the offending commit in the list of people
to CC.


Now you are adding reset_control_rearm() before disabling clocks to the error
handling in brcm_ahci_resume(), however in the error handing in
brcm_ahci_probe(), we call reset_control_rearm() after disabling clocks.
Why should the error handling in brcm_ahci_resume() not match that of
brcm_ahci_probe() ?


I am confused as to why the error handling in brcm_ahci_probe() is calling both
reset_control_rearm() and reset_control_reset().

The documentation for reset_control, explicitly says not to do this:
https://github.com/torvalds/linux/blob/v7.1-rc6/drivers/reset/core.c#L365-L366

And in libahci_platform.c, we always do either:
return reset_control_rearm() or return reset_control_reset():
https://github.com/torvalds/linux/blob/v7.1-rc6/drivers/ata/libahci_platform.c#L188-L193

Too bad that this driver is not using the generic AHCI functions in
libahci_platform.c.


Kind regards,
Niklas

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume()
  2026-06-04 10:03 ` Niklas Cassel
@ 2026-06-04 11:31   ` Niklas Cassel
  0 siblings, 0 replies; 4+ messages in thread
From: Niklas Cassel @ 2026-06-04 11:31 UTC (permalink / raw)
  To: Wentao Liang, Florian Fainelli; +Cc: dlemoal, linux-ide, linux-kernel, stable

On Thu, Jun 04, 2026 at 12:03:53PM +0200, Niklas Cassel wrote:

(snip)

> The documentation for reset_control, explicitly says not to do this:
> https://github.com/torvalds/linux/blob/v7.1-rc6/drivers/reset/core.c#L365-L366
> 
> And in libahci_platform.c, we always do either:
> return reset_control_rearm() or return reset_control_reset():
> https://github.com/torvalds/linux/blob/v7.1-rc6/drivers/ata/libahci_platform.c#L188-L193

I realize that I am stupid...

The code is doing it on two different reset handles.

My comment that the cleanup in brcm_ahci_resume() should match that in
brcm_ahci_resume() probe still stands.

i.e. you should also add a call to:
reset_control_assert(priv->rcdev_ahci);

And you should do it after disabling clocks, just as brcm_ahci_resume().


Kind regards,
Niklas

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-06-04 11:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-03 10:24 [PATCH] ata: ahci_brcm: fix reset refcount leak in brcm_ahci_resume() Wentao Liang
2026-06-03 10:39 ` sashiko-bot
2026-06-04 10:03 ` Niklas Cassel
2026-06-04 11:31   ` Niklas Cassel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.