Re: [PATCH] rtc: meson: fix refcount leak in meson_rtc_get_bus
| Newsgroups | org.infradead.lists.linux-amlogic |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Bogus fix attempting to fix a non-existent refcount leak, which violates the reset API contract and introduces a potential counter underflow. -- commit dec7a1c708a5b28d1344bf6fb038df54d6001df3 Author: WenTao Liang <[email protected]> rtc: meson: fix refcount leak in meson_rtc_get_bus This commit adds calls to reset_control_rearm() in both the error and success paths of meson_rtc_get_bus() after triggering a reset. The intention is to prevent a triggered_count leak on shared reset controls. > diff --git a/drivers/rtc/rtc-meson.c b/drivers/rtc/rtc-meson.c > index 21eceb9e2e134..3c45cd761a15a 100644 > --- a/drivers/rtc/rtc-meson.c > +++ b/drivers/rtc/rtc-meson.c > @@ -146,8 +146,12 @@ static int meson_rtc_get_bus(struct meson_rtc *rtc) > dev_warn(rtc->dev, "failed to get bus, resetting RTC\n"); > > ret = reset_control_reset(rtc->reset); > - if (ret) > + if (ret) { > + reset_control_rearm(rtc->reset); [Severity: Medium] Is this fix applicable to this driver's reset control? The reset control rtc->reset is acquired as an exclusive control using devm_reset_control_get(). Exclusive controls do not track triggered_count, so calling reset_control_rearm() is a no-op in this context, meaning there was no leak to fix. Additionally, if this were a shared reset control, would calling reset_control_rearm() on the error path cause a counter underflow? The reset core already handles the rollback internally by decrementing triggered_count if the underlying reset fails. Adding a manual reset_control_rearm() here on failure would decrement it a second time, which could trigger a WARN_ON() for dropping below zero. > + return ret; > + } > + > + reset_control_rearm(rtc->reset); > } > > dev_err(rtc->dev, "bus is not ready\n"); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1 _______________________________________________ linux-amlogic mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-amlogic