interrupt_cnt_probe() calls mutex_init() but neither this driver
nor the counter core issues a matching mutex_destroy() on unbind,
which leaks the lock debug state when CONFIG_DEBUG_MUTEXES is
enabled.

Switch to devm_mutex_init() so the mutex is torn down in the same
devm scope it was set up in.

Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter")
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
---
v2:
- Add Fixes tag and clarify the leak is only visible under
  CONFIG_DEBUG_MUTEXES (William, Joshua)
- Add Reviewed-by from Joshua

v1: https://lore.kernel.org/all/20260523184418.7586-1-sozdayvek@gmail.com/

 drivers/counter/interrupt-cnt.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c
index e6100b5fb..cd475382a 100644
--- a/drivers/counter/interrupt-cnt.c
+++ b/drivers/counter/interrupt-cnt.c
@@ -233,7 +233,9 @@ static int interrupt_cnt_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	mutex_init(&priv->lock);
+	ret = devm_mutex_init(dev, &priv->lock);
+	if (ret)
+		return ret;
 
 	ret = devm_counter_add(dev, counter);
 	if (ret < 0)
-- 
2.43.0

On Mon, May 25, 2026 at 08:11:52PM +0500, Stepan Ionichev wrote:
> interrupt_cnt_probe() calls mutex_init() but neither this driver
> nor the counter core issues a matching mutex_destroy() on unbind,
> which leaks the lock debug state when CONFIG_DEBUG_MUTEXES is
> enabled.
> 
> Switch to devm_mutex_init() so the mutex is torn down in the same
> devm scope it was set up in.
> 
> Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter")

The mutex_init() code was added in 7351312632e8 ("counter:
interrupt-cnt: Protect enable/disable OPs with mutex"), so the Fixes tag
should refer to that commit.

William Breathitt Gray

On Wed, 27 May 2026 15:56:31 +0900
William Breathitt Gray <wbg@kernel.org> wrote:

> On Mon, May 25, 2026 at 08:11:52PM +0500, Stepan Ionichev wrote:
> > interrupt_cnt_probe() calls mutex_init() but neither this driver
> > nor the counter core issues a matching mutex_destroy() on unbind,
> > which leaks the lock debug state when CONFIG_DEBUG_MUTEXES is
> > enabled.
> > 
> > Switch to devm_mutex_init() so the mutex is torn down in the same
> > devm scope it was set up in.
> > 
> > Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter")  
> 
> The mutex_init() code was added in 7351312632e8 ("counter:
> interrupt-cnt: Protect enable/disable OPs with mutex"), so the Fixes tag
> should refer to that commit.
> 

Not a fix.   For a long time it was common to take the view that
mutex_destroy() was only useful if you had marginally complex lifetime
handling in a driver and it might help detect bugs.

Now devm_mutex_init() makes it easier to do, the barrier to deciding
to have that protection is reduced, so we apply it to more drivers
(for IIO I now ask for this always).  That doesn't make it a fix as such,
more of an update to modern approaches and definitely not suitable for
the backports that will likely cause.  So I'd drop the fixes tag.

Jonathan

> William Breathitt Gray
>