kernel.git/drivers/gpio/gpiolib-cdev.c, branch linux-6.17.y

gpio: cdev: make sure the cdev fd is still active before emitting events

2025-12-01T10:45:59Z

[ Upstream commit d4cd0902c156b2ca60fdda8cd8b5bcb4b0e9ed64 ] With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released. Fixes: 40b7c49950bd ("gpio: cdev: put emitting the line state events on a workqueue") Reported-by: Alexander Sverdlin Closes: https://lore.kernel.org/all/5d605f7fc99456804911403102a4fe999a14cc85.camel@siemens.com/ Tested-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20251117-gpio-cdev-get-file-v1-1-28a16b5985b8@linaro.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpiolib: don't allow setting values on input lines

2025-04-07T07:00:48Z

Some drivers as well as the character device and sysfs code check whether the line actually is in output mode before allowing the user to set a value. However, GPIO value setters now return integer values and can indicate failures. This allows us to move these checks into the core code. Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250311-gpio-set-check-output-v1-1-d971bca9e6fa@linaro.org Signed-off-by: Bartosz Golaszewski

gpio: cdev: use raw notifier for line state events

2025-03-13T08:20:12Z

We use a notifier to implement the mechanism of informing the user-space about changes in GPIO line status. We register with the notifier when the GPIO character device file is opened and unregister when the last reference to the associated file descriptor is dropped. Since commit fcc8b637c542 ("gpiolib: switch the line state notifier to atomic") we use the atomic notifier variant. Atomic notifiers call rcu_synchronize in atomic_notifier_chain_unregister() which caused a significant performance regression in some circumstances, observed by user-space when calling close() on the GPIO device file descriptor. Replace the atomic notifier with the raw variant and provide synchronization with a read-write spinlock. Fixes: fcc8b637c542 ("gpiolib: switch the line state notifier to atomic") Reported-by: David Jander Closes: https://lore.kernel.org/all/20250311110034.53959031@erd003.prtnl/ Tested-by: David Jander Tested-by: Kent Gibson Link: https://lore.kernel.org/r/20250311-gpiolib-line-state-raw-notifier-v2-1-138374581e1e@linaro.org Signed-off-by: Bartosz Golaszewski

gpiolib: cdev: use !mem_is_zero() instead of memchr_inv(s, 0, n)

2024-11-12T08:46:17Z

Use the mem_is_zero() helper where possible. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241110201706.16614-1-andy.shevchenko@gmail.com Signed-off-by: Bartosz Golaszewski

gpio: cdev: don't report GPIOs requested as interrupts as used

2024-11-04T08:08:11Z

GPIOs used as shared irqs can still be requested by user-space (or kernel drivers for that matter) yet we report them as used over the chardev ABI. Drop the test for FLAG_USED_AS_IRQ from gpio_desc_to_lineinfo(). Reviewed-by: Kent Gibson Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20241031200842.22712-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski

gpiolib: avoid format string weakness in workqueue interface

2024-10-31T12:43:09Z

Using a string literal as a format string is a possible bug when the string contains '%' characters: drivers/gpio/gpiolib-cdev.c:2813:48: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] 2813 | gdev->line_state_wq = alloc_ordered_workqueue(dev_name(&gdev->dev), | ^~~~~~~~~~~~~~~~~~~~ drivers/gpio/gpiolib-cdev.c:2813:48: note: treat the string as an argument to avoid this 2813 | gdev->line_state_wq = alloc_ordered_workqueue(dev_name(&gdev->dev), | ^ | "%s", Do as clang suggests and use a trivial "%s" format string. Fixes: 7b9b77a8bba9 ("gpiolib: add a per-gpio_device line state notification workqueue") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20241028142152.750650-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski

gpiolib: cdev: remove redundant store of debounce_period_us

2024-10-22T07:15:30Z

debounce_setup() stores the debounce_period_us if the driver supports debounce, but the debounce_period_us is also stored where debounce_setup() is called, independent of whether the debounce is being perfomed by hardware or software. Remove the redundant storing of the debounce_period_us in debounce_setup(). Signed-off-by: Kent Gibson Link: https://lore.kernel.org/r/20241020115238.170994-1-warthog618@gmail.com Signed-off-by: Bartosz Golaszewski

gpiolib: notify user-space about in-kernel line state changes

2024-10-22T06:59:09Z

We currently only notify user-space about line config changes that are made from user-space. Any kernel config changes are not signalled. Let's improve the situation by emitting the events closer to the source. To that end let's call the relevant notifier chain from the functions setting direction, gpiod_set_config(), gpiod_set_consumer_name() and gpiod_toggle_active_low(). This covers all the options that we can inform the user-space about. We ignore events which don't have corresponding flags exported to user-space on purpose - otherwise the user would see a config-changed event but the associated line-info would remain unchanged. gpiod_direction_output/input() can be called from any context. Fortunately, we now emit line state events using an atomic notifier chain, so it's no longer an issue. Let's also add non-notifying wrappers around the direction setters in order to not emit superfluous reconfigure events when requesting the lines as the initial config should be part of the request notification. Use gpio_do_set_config() instead of gpiod_set_debounce() for configuring debouncing via hardware from the character device code to avoid multiple reconfigure events. Reviewed-by: Kent Gibson Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-8-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski

gpiolib: switch the line state notifier to atomic

2024-10-22T06:59:09Z

With everything else ready, we can now switch to using the atomic notifier for line state events which will allow us to notify user-space about direction changes from atomic context. Reviewed-by: Kent Gibson Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-7-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski

gpio: cdev: put emitting the line state events on a workqueue

2024-10-22T06:59:09Z

In order to allow line state notifications to be emitted from atomic context (for instance: from gpiod_direction_input/output()), we must stop calling any sleeping functions in lineinfo_changed_notify(). To that end let's use the new workqueue. Let's atomically allocate small structures containing the required data and fill it with information immediately upon being notified about the change except for the pinctrl state which will be retrieved later from process context. We can pretty reliably do this as pin functions are typically set once per boot. Let's make sure to bump the reference count of GPIO device and the GPIO character device file descriptor to keep both alive until the event was queued. Reviewed-by: Kent Gibson Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-6-c79135e58a1c@linaro.org Signed-off-by: Bartosz Golaszewski