public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs
@ 2026-02-12 13:35 Bartosz Golaszewski
  2026-02-13  8:32 ` Johan Hovold
  2026-02-18  8:43 ` Bartosz Golaszewski
  0 siblings, 2 replies; 5+ messages in thread
From: Bartosz Golaszewski @ 2026-02-12 13:35 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski
  Cc: linux-gpio, linux-kernel, Bartosz Golaszewski, stable

Currently if we export a GPIO over sysfs and unbind the parent GPIO
controller, the exported attribute will remain under /sys/class/gpio
because once we remove the parent device, we can no longer associate the
descriptor with it in gpiod_unexport() and never drop the final
reference.

Rework the teardown code: provide an unlocked variant of
gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken
before unregistering the parent device itself. This is done to prevent
any new exports happening before we unregister the device completely.

Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/gpio/gpiolib-sysfs.c | 106 ++++++++++++++++++-----------------
 1 file changed, 55 insertions(+), 51 deletions(-)

diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
index cd553acf3055e..d4a46a0a37d8f 100644
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -919,63 +919,68 @@ int gpiod_export_link(struct device *dev, const char *name,
 }
 EXPORT_SYMBOL_GPL(gpiod_export_link);
 
-/**
- * gpiod_unexport - reverse effect of gpiod_export()
- * @desc: GPIO to make unavailable
- *
- * This is implicit on gpiod_free().
- */
-void gpiod_unexport(struct gpio_desc *desc)
+static void gpiod_unexport_unlocked(struct gpio_desc *desc)
 {
 	struct gpiod_data *tmp, *desc_data = NULL;
 	struct gpiodev_data *gdev_data;
 	struct gpio_device *gdev;
 
-	if (!desc) {
-		pr_warn("%s: invalid GPIO\n", __func__);
+	if (!test_bit(GPIOD_FLAG_EXPORT, &desc->flags))
 		return;
-	}
 
-	scoped_guard(mutex, &sysfs_lock) {
-		if (!test_bit(GPIOD_FLAG_EXPORT, &desc->flags))
-			return;
-
-		gdev = gpiod_to_gpio_device(desc);
-		gdev_data = gdev_get_data(gdev);
-		if (!gdev_data)
-			return;
+	gdev = gpiod_to_gpio_device(desc);
+	gdev_data = gdev_get_data(gdev);
+	if (!gdev_data)
+		return;
 
-		list_for_each_entry(tmp, &gdev_data->exported_lines, list) {
-			if (gpiod_is_equal(desc, tmp->desc)) {
-				desc_data = tmp;
-				break;
-			}
+	list_for_each_entry(tmp, &gdev_data->exported_lines, list) {
+		if (gpiod_is_equal(desc, tmp->desc)) {
+			desc_data = tmp;
+			break;
 		}
+	}
 
-		if (!desc_data)
-			return;
+	if (!desc_data)
+		return;
 
-		list_del(&desc_data->list);
-		clear_bit(GPIOD_FLAG_EXPORT, &desc->flags);
+	list_del(&desc_data->list);
+	clear_bit(GPIOD_FLAG_EXPORT, &desc->flags);
 #if IS_ENABLED(CONFIG_GPIO_SYSFS_LEGACY)
-		sysfs_put(desc_data->value_kn);
-		device_unregister(desc_data->dev);
-
-		/*
-		 * Release irq after deregistration to prevent race with
-		 * edge_store.
-		 */
-		if (desc_data->irq_flags)
-			gpio_sysfs_free_irq(desc_data);
+	sysfs_put(desc_data->value_kn);
+	device_unregister(desc_data->dev);
+
+	/*
+	 * Release irq after deregistration to prevent race with
+	 * edge_store.
+	 */
+	if (desc_data->irq_flags)
+		gpio_sysfs_free_irq(desc_data);
 #endif /* CONFIG_GPIO_SYSFS_LEGACY */
 
-		sysfs_remove_groups(desc_data->parent,
-				    desc_data->chip_attr_groups);
-	}
+	sysfs_remove_groups(desc_data->parent,
+			    desc_data->chip_attr_groups);
 
 	mutex_destroy(&desc_data->mutex);
 	kfree(desc_data);
 }
+
+/**
+ * gpiod_unexport - reverse effect of gpiod_export()
+ * @desc: GPIO to make unavailable
+ *
+ * This is implicit on gpiod_free().
+ */
+void gpiod_unexport(struct gpio_desc *desc)
+{
+	if (!desc) {
+		pr_warn("%s: invalid GPIO\n", __func__);
+		return;
+	}
+
+	guard(mutex)(&sysfs_lock);
+
+	gpiod_unexport_unlocked(desc);
+}
 EXPORT_SYMBOL_GPL(gpiod_unexport);
 
 int gpiochip_sysfs_register(struct gpio_device *gdev)
@@ -1054,29 +1059,28 @@ void gpiochip_sysfs_unregister(struct gpio_device *gdev)
 	struct gpio_desc *desc;
 	struct gpio_chip *chip;
 
-	scoped_guard(mutex, &sysfs_lock) {
-		data = gdev_get_data(gdev);
-		if (!data)
-			return;
+	guard(mutex)(&sysfs_lock);
 
-#if IS_ENABLED(CONFIG_GPIO_SYSFS_LEGACY)
-		device_unregister(data->cdev_base);
-#endif /* CONFIG_GPIO_SYSFS_LEGACY */
-		device_unregister(data->cdev_id);
-		kfree(data);
-	}
+	data = gdev_get_data(gdev);
+	if (!data)
+		return;
 
 	guard(srcu)(&gdev->srcu);
-
 	chip = srcu_dereference(gdev->chip, &gdev->srcu);
 	if (!chip)
 		return;
 
 	/* unregister gpiod class devices owned by sysfs */
 	for_each_gpio_desc_with_flag(chip, desc, GPIOD_FLAG_SYSFS) {
-		gpiod_unexport(desc);
+		gpiod_unexport_unlocked(desc);
 		gpiod_free(desc);
 	}
+
+#if IS_ENABLED(CONFIG_GPIO_SYSFS_LEGACY)
+	device_unregister(data->cdev_base);
+#endif /* CONFIG_GPIO_SYSFS_LEGACY */
+	device_unregister(data->cdev_id);
+	kfree(data);
 }
 
 /*
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs
  2026-02-12 13:35 [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs Bartosz Golaszewski
@ 2026-02-13  8:32 ` Johan Hovold
  2026-02-13 18:11   ` Bartosz Golaszewski
  2026-02-18  8:43 ` Bartosz Golaszewski
  1 sibling, 1 reply; 5+ messages in thread
From: Johan Hovold @ 2026-02-13  8:32 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio, linux-kernel,
	stable

On Thu, Feb 12, 2026 at 02:35:05PM +0100, Bartosz Golaszewski wrote:
> Currently if we export a GPIO over sysfs and unbind the parent GPIO
> controller, the exported attribute will remain under /sys/class/gpio
> because once we remove the parent device, we can no longer associate the
> descriptor with it in gpiod_unexport() and never drop the final
> reference.

Is this a recent regression? I'm quite sure fixed this once back in
2015.

> Rework the teardown code: provide an unlocked variant of
> gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken
> before unregistering the parent device itself. This is done to prevent
> any new exports happening before we unregister the device completely.

So please add a Fixes tag here to document this.

> Cc: stable@vger.kernel.org
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Johan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs
  2026-02-13  8:32 ` Johan Hovold
@ 2026-02-13 18:11   ` Bartosz Golaszewski
  2026-02-16  7:54     ` Johan Hovold
  0 siblings, 1 reply; 5+ messages in thread
From: Bartosz Golaszewski @ 2026-02-13 18:11 UTC (permalink / raw)
  To: Johan Hovold
  Cc: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski,
	linux-gpio, linux-kernel, stable

On Fri, 13 Feb 2026 09:32:47 +0100, Johan Hovold <johan@kernel.org> said:
> On Thu, Feb 12, 2026 at 02:35:05PM +0100, Bartosz Golaszewski wrote:
>> Currently if we export a GPIO over sysfs and unbind the parent GPIO
>> controller, the exported attribute will remain under /sys/class/gpio
>> because once we remove the parent device, we can no longer associate the
>> descriptor with it in gpiod_unexport() and never drop the final
>> reference.
>
> Is this a recent regression? I'm quite sure fixed this once back in
> 2015.
>

Yes, that sometimes happens. There have been close to 100 commits between your
fix and now, including two major reworks.

>> Rework the teardown code: provide an unlocked variant of
>> gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken
>> before unregistering the parent device itself. This is done to prevent
>> any new exports happening before we unregister the device completely.
>
> So please add a Fixes tag here to document this.
>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> Johan
>

It bisects to this commit, though it's possible it's a mix of several changes.

Fixes: 1cd53df733c2 ("gpio: sysfs: don't look up exported lines as
class devices")

Bartosz

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs
  2026-02-13 18:11   ` Bartosz Golaszewski
@ 2026-02-16  7:54     ` Johan Hovold
  0 siblings, 0 replies; 5+ messages in thread
From: Johan Hovold @ 2026-02-16  7:54 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Bartosz Golaszewski, Linus Walleij, linux-gpio, linux-kernel,
	stable

On Fri, Feb 13, 2026 at 10:11:47AM -0800, Bartosz Golaszewski wrote:
> On Fri, 13 Feb 2026 09:32:47 +0100, Johan Hovold <johan@kernel.org> said:
> > On Thu, Feb 12, 2026 at 02:35:05PM +0100, Bartosz Golaszewski wrote:
> >> Currently if we export a GPIO over sysfs and unbind the parent GPIO
> >> controller, the exported attribute will remain under /sys/class/gpio
> >> because once we remove the parent device, we can no longer associate the
> >> descriptor with it in gpiod_unexport() and never drop the final
> >> reference.
> >
> > Is this a recent regression? I'm quite sure fixed this once back in
> > 2015.
> 
> Yes, that sometimes happens. There have been close to 100 commits between your
> fix and now, including two major reworks.

It sure does. I was just pointing out that this is a regression, which
wasn't apparent from your commit message.

> >> Rework the teardown code: provide an unlocked variant of
> >> gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken
> >> before unregistering the parent device itself. This is done to prevent
> >> any new exports happening before we unregister the device completely.
> >
> > So please add a Fixes tag here to document this.
> >
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

> It bisects to this commit, though it's possible it's a mix of several changes.
> 
> Fixes: 1cd53df733c2 ("gpio: sysfs: don't look up exported lines as
> class devices")

That's the commit from last summer that I suspected as well after a
quick glance at the code (hence the word "recent" above).

We don't want anyone trying to backport this further back than needed.

Johan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs
  2026-02-12 13:35 [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs Bartosz Golaszewski
  2026-02-13  8:32 ` Johan Hovold
@ 2026-02-18  8:43 ` Bartosz Golaszewski
  1 sibling, 0 replies; 5+ messages in thread
From: Bartosz Golaszewski @ 2026-02-18  8:43 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Bartosz Golaszewski
  Cc: linux-gpio, linux-kernel, stable


On Thu, 12 Feb 2026 14:35:05 +0100, Bartosz Golaszewski wrote:
> Currently if we export a GPIO over sysfs and unbind the parent GPIO
> controller, the exported attribute will remain under /sys/class/gpio
> because once we remove the parent device, we can no longer associate the
> descriptor with it in gpiod_unexport() and never drop the final
> reference.
> 
> Rework the teardown code: provide an unlocked variant of
> gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken
> before unregistering the parent device itself. This is done to prevent
> any new exports happening before we unregister the device completely.
> 
> [...]

Applied, thanks!

[1/1] gpio: sysfs: fix chip removal with GPIOs exported over sysfs
      https://git.kernel.org/brgl/c/6766f59012301f1bf3f46c6e7149caca45d92309

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-02-18  8:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-12 13:35 [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs Bartosz Golaszewski
2026-02-13  8:32 ` Johan Hovold
2026-02-13 18:11   ` Bartosz Golaszewski
2026-02-16  7:54     ` Johan Hovold
2026-02-18  8:43 ` Bartosz Golaszewski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox