Re: [PATCH] gpio: shared: fix a race in shared desc release path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] gpio: shared: missing mutex_unlock() in gpio_shared_release()
--

commit 5cfdf2552fd680712c24f5438a69c1cd0f6f788d
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

gpio: shared: fix a race in shared desc release path

This commit switches gpiod_shared_put() from kref_put() to
kref_put_mutex() so that entry->lock is acquired atomically when the last
reference is dropped, and removes guard(mutex)(&entry->lock) from
gpio_shared_release().

> diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
> index 8c9ac9d933049..f6cf298e28b08 100644
> --- a/drivers/gpio/gpiolib-shared.c
> +++ b/drivers/gpio/gpiolib-shared.c
> @@ -635,8 +635,6 @@ static void gpio_shared_release(struct kref *kref)
>  		container_of(kref, struct gpio_shared_entry, ref);
>  	struct gpio_shared_desc *shared_desc;
>  
> -	guard(mutex)(&entry->lock);
> -
>  	shared_desc = entry->shared_desc;
>  	gpio_device_put(shared_desc->desc->gdev);
>  	mutex_destroy(&shared_desc->mutex);
> @@ -648,7 +646,7 @@ static void gpiod_shared_put(void *data)
>  {
>  	struct gpio_shared_entry *entry = data;
>  
> -	kref_put(&entry->ref, gpio_shared_release);
> +	kref_put_mutex(&entry->ref, gpio_shared_release, &entry->lock);
>  }

[Severity: High]
Does gpio_shared_release() leave entry->lock locked when the last
reference is dropped?  kref_put_mutex() acquires entry->lock via
refcount_dec_and_mutex_lock() and requires the release callback to call
mutex_unlock(&entry->lock), so removing guard(mutex)(&entry->lock) without
adding mutex_unlock(&entry->lock) causes any later caller acquiring
entry->lock, such as devm_gpiod_shared_get(), to deadlock.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-gpio-shared-refcnt-race-v1-1-79c9167505ab@oss.qualcomm.com?part=1