Call mutex_unlock() before returning an error in ee1004_probe()

Fixes: 55d57ef6fa97 ("eeprom: ee1004: Use devres for bus data cleanup")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 drivers/misc/eeprom/ee1004.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/eeprom/ee1004.c b/drivers/misc/eeprom/ee1004.c
index d4aeeb2b2169..adba67cef1e7 100644
--- a/drivers/misc/eeprom/ee1004.c
+++ b/drivers/misc/eeprom/ee1004.c
@@ -272,8 +272,10 @@ static int ee1004_probe(struct i2c_client *client)
 	}
 
 	err = devm_add_action_or_reset(&client->dev, ee1004_cleanup_bus_data, bd);
-	if (err < 0)
+	if (err < 0) {
+		mutex_unlock(&ee1004_bus_lock);
 		return err;
+	}
 
 	i2c_set_clientdata(client, bd);
 
-- 
2.43.0

Am 12.07.24 um 16:04 schrieb Dan Carpenter:

> Call mutex_unlock() before returning an error in ee1004_probe()

Good catch, but it seems that i messed up the locking part event more, sorry.
Because if devm_add_action_or_reset() does a reset operation, a deadlock
will occur since ee1004_cleanup_bus_data() will try to lock the mutex again.

I can provide a cleanup patch to fix both problems.

Thanks,
Armin Wolf

>
> Fixes: 55d57ef6fa97 ("eeprom: ee1004: Use devres for bus data cleanup")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
>   drivers/misc/eeprom/ee1004.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/eeprom/ee1004.c b/drivers/misc/eeprom/ee1004.c
> index d4aeeb2b2169..adba67cef1e7 100644
> --- a/drivers/misc/eeprom/ee1004.c
> +++ b/drivers/misc/eeprom/ee1004.c
> @@ -272,8 +272,10 @@ static int ee1004_probe(struct i2c_client *client)
>   	}
>
>   	err = devm_add_action_or_reset(&client->dev, ee1004_cleanup_bus_data, bd);
> -	if (err < 0)
> +	if (err < 0) {
> +		mutex_unlock(&ee1004_bus_lock);
>   		return err;
> +	}
>
>   	i2c_set_clientdata(client, bd);
>

> Call mutex_unlock() before returning an error in ee1004_probe()

Under which circumstances would you become interested to apply a statement
like “guard(mutex)(&ee1004_bus_lock);”?
https://elixir.bootlin.com/linux/v6.10-rc7/source/include/linux/mutex.h#L196


Would you like to refer to the function name “ee1004_probe” in the summary phrase?

Regards,
Markus

On Fri, Jul 12, 2024 at 05:42:12PM +0200, Markus Elfring wrote:
> > Call mutex_unlock() before returning an error in ee1004_probe()
> 
> Under which circumstances would you become interested to apply a statement
> like “guard(mutex)(&ee1004_bus_lock);”?
> https://elixir.bootlin.com/linux/v6.10-rc7/source/include/linux/mutex.h#L196
> 
> 
> Would you like to refer to the function name “ee1004_probe” in the summary phrase?


Hi,

This is the semi-friendly patch-bot of Greg Kroah-Hartman.

Markus, you seem to have sent a nonsensical or otherwise pointless
review comment to a patch submission on a Linux kernel developer mailing
list.  I strongly suggest that you not do this anymore.  Please do not
bother developers who are actively working to produce patches and
features with comments that, in the end, are a waste of time.

Patch submitter, please ignore Markus's suggestion; you do not need to
follow it at all.  The person/bot/AI that sent it is being ignored by
almost all Linux kernel maintainers for having a persistent pattern of
behavior of producing distracting and pointless commentary, and
inability to adapt to feedback.  Please feel free to also ignore emails
from them.

thanks,

greg k-h's patch email bot

On Fri, Jul 12, 2024, at 16:04, Dan Carpenter wrote:
> Call mutex_unlock() before returning an error in ee1004_probe()
>
> Fixes: 55d57ef6fa97 ("eeprom: ee1004: Use devres for bus data cleanup")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>

Acked-by: Arnd Bergmann <arnd@arndb.de>