[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e0ea95b88285cfbf71a175fc8c60f6b2cfd28dc8.camel@pengutronix.de>
Date: Thu, 08 Jan 2026 10:39:31 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Krzysztof
Kozlowski <krzk@...nel.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/15] reset: use lock guards in reset core
On Mo, 2026-01-05 at 15:15 +0100, Bartosz Golaszewski wrote:
> Simplify the locking code in reset core by using lock guard from
> linux/cleanup.h.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
> ---
> drivers/reset/core.c | 51 +++++++++++++++++++++++----------------------------
> 1 file changed, 23 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 39bedf990223212998fa8ed4cda517529f94ee23..ffb811cbc6460b48dd833d3560d6538eea2fd5c0 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -1069,22 +1064,23 @@ __of_reset_control_get(struct device_node *node, const char *id, int index,
> }
> }
>
> - mutex_lock(&reset_list_mutex);
> + guard(mutex)(&reset_list_mutex);
> +
This breaks the __reset_add_reset_gpio_device() error path,
which jumps to the of_put: label without reset_list_mutex locked.
See [1], where I made the same mistake:
[1] https://lore.kernel.org/all/20240928222702.GX3550746@ZenIV/
regards
Philipp
Powered by blists - more mailing lists