gpio: cdev: use raw notifier for line state events

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: cdev: use raw notifier for line state events

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 <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Tested-by: David Jander <[email protected]>
Tested-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/20250311-gpiolib-line-state-raw-notifier-v2-1-138374581e1e@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

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

Use the mem_is_zero() helper where possible.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.or

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

Use the mem_is_zero() helper where possible.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

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

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

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

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 <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: avoid format string weakness in workqueue interface

Using a string literal as a format string is a possible bug when the
string contains '%' characters:

drivers/gpio/gpiolib-cdev.c:2813:48

gpiolib: avoid format string weakness in workqueue interface

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: remove redundant store of debounce_period_us

debounce_setup() stores the debounce_period_us if the driver supports
debounce, but the debounce_period_us is also stored where debounce_s

gpiolib: cdev: remove redundant store of debounce_period_us

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

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

We currently only notify user-space about line config changes that are
made from user-space. Any kernel config changes are not signalled

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

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 <[email protected]>
Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-8-c79135e58a1c@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: switch the line state notifier to atomic

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 dire

gpiolib: switch the line state notifier to atomic

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 <[email protected]>
Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-7-c79135e58a1c@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

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

In order to allow line state notifications to be emitted from atomic
context (for instance: from gpiod_direction_input/output()), we mus

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

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 <[email protected]>
Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-6-c79135e58a1c@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: add a per-gpio_device line state notification workqueue

In order to prepare the line state notification mechanism for working in
atomic context as well, add a dedicated, high-priority, orde

gpiolib: add a per-gpio_device line state notification workqueue

In order to prepare the line state notification mechanism for working in
atomic context as well, add a dedicated, high-priority, ordered
workqueue to GPIO device which will be used to queue the events fron any
context for them to be emitted always in process context.

Reviewed-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-5-c79135e58a1c@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: cdev: prepare gpio_desc_to_lineinfo() for being called from atomic

In order to prepare gpio_desc_to_lineinfo() to being called from atomic
context, add a new argument - bool atomic - which, if

gpio: cdev: prepare gpio_desc_to_lineinfo() for being called from atomic

In order to prepare gpio_desc_to_lineinfo() to being called from atomic
context, add a new argument - bool atomic - which, if set, indicates
that no sleeping functions must be called (currently: only
pinctrl_gpio_can_use_line()).

Reviewed-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-4-c79135e58a1c@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: cdev: go back to storing debounce period in the GPIO descriptor

This effectively reverts commits 9344e34e7992 ("gpiolib: cdev: relocate
debounce_period_us from struct gpio_desc") and d8543cbaf

gpio: cdev: go back to storing debounce period in the GPIO descriptor

This effectively reverts commits 9344e34e7992 ("gpiolib: cdev: relocate
debounce_period_us from struct gpio_desc") and d8543cbaf979 ("gpiolib:
remove debounce_period_us from struct gpio_desc") and goes back to
storing the debounce period in microseconds in the GPIO descriptor

We're doing it in preparation for notifying the user-space about
in-kernel line config changes.

Reviewed-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/20241018-gpio-notify-in-kernel-events-v5-3-c79135e58a1c@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: cdev: update flags at once when reconfiguring from user-space

Make updating the descriptor flags when reconfiguring from user-space
consistent with the rest of the codebase: read the current s

gpio: cdev: update flags at once when reconfiguring from user-space

Make updating the descriptor flags when reconfiguring from user-space
consistent with the rest of the codebase: read the current state
atomically, update it according to user's instructions and write it back
atomically as well.

Reviewed-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/20241004-gpio-notify-in-kernel-events-v1-3-8ac29e1df4fe@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: Fix reference to linereq_set_config_unlocked()

With the change to cleanup.h guards, linereq_set_config_unlocked() was
collapsed into linereq_set_config(), but documentation referencin

gpiolib: cdev: Fix reference to linereq_set_config_unlocked()

With the change to cleanup.h guards, linereq_set_config_unlocked() was
collapsed into linereq_set_config(), but documentation referencing it
was not updated to reflect that change.

Update the reference to linereq_set_config().

Signed-off-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

[tree-wide] finally take no_llseek out

no_llseek had been defined to NULL two years ago, in commit 868941b14441
("fs: remove no_llseek")

To quote that commit,

At -rc1 we'll need do a mechanical

[tree-wide] finally take no_llseek out

no_llseek had been defined to NULL two years ago, in commit 868941b14441
("fs: remove no_llseek")

To quote that commit,

At -rc1 we'll need do a mechanical removal of no_llseek -

git grep -l -w no_llseek | grep -v porting.rst | while read i; do
sed -i '/\<no_llseek\>/d' $i
done

would do it.

Unfortunately, that hadn't been done. Linus, could you do that now, so
that we could finally put that thing to rest? All instances are of the
form
.llseek = no_llseek,
so it's obviously safe.

Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

gpiolib: Update the kernel documentation - add Return sections

$ scripts/kernel-doc -v -none -Wall drivers/gpio/gpiolib* 2>&1 | grep -w warning | wc -l
67

Fix these by adding Return sections. While

gpiolib: Update the kernel documentation - add Return sections

$ scripts/kernel-doc -v -none -Wall drivers/gpio/gpiolib* 2>&1 | grep -w warning | wc -l
67

Fix these by adding Return sections. While at it, make sure all of
Return sections use the same style.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: Ignore reconfiguration without direction

linereq_set_config() behaves badly when direction is not set.
The configuration validation is borrowed from linereq_create(), where,
to verify

gpiolib: cdev: Ignore reconfiguration without direction

linereq_set_config() behaves badly when direction is not set.
The configuration validation is borrowed from linereq_create(), where,
to verify the intent of the user, the direction must be set to in order to
effect a change to the electrical configuration of a line. But, when
applied to reconfiguration, that validation does not allow for the unset
direction case, making it possible to clear flags set previously without
specifying the line direction.

Adding to the inconsistency, those changes are not immediately applied by
linereq_set_config(), but will take effect when the line value is next get
or set.

For example, by requesting a configuration with no flags set, an output
line with GPIO_V2_LINE_FLAG_ACTIVE_LOW and GPIO_V2_LINE_FLAG_OPEN_DRAIN
set could have those flags cleared, inverting the sense of the line and
changing the line drive to push-pull on the next line value set.

Skip the reconfiguration of lines for which the direction is not set, and
only reconfigure the lines for which direction is set.

Fixes: a54756cb24ea ("gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL")
Signed-off-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: Disallow reconfiguration without direction (uAPI v1)

linehandle_set_config() behaves badly when direction is not set.
The configuration validation is borrowed from linehandle_create()

gpiolib: cdev: Disallow reconfiguration without direction (uAPI v1)

linehandle_set_config() behaves badly when direction is not set.
The configuration validation is borrowed from linehandle_create(), where,
to verify the intent of the user, the direction must be set to in order
to effect a change to the electrical configuration of a line. But, when
applied to reconfiguration, that validation does not allow for the unset
direction case, making it possible to clear flags set previously without
specifying the line direction.

Adding to the inconsistency, those changes are not immediately applied by
linehandle_set_config(), but will take effect when the line value is next
get or set.

For example, by requesting a configuration with no flags set, an output
line with GPIOHANDLE_REQUEST_ACTIVE_LOW and GPIOHANDLE_REQUEST_OPEN_DRAIN
requested could have those flags cleared, inverting the sense of the line
and changing the line drive to push-pull on the next line value set.

Ensure the intent of the user by disallowing configurations which do not
have direction set, returning an error to userspace to indicate that the
configuration is invalid.

And, for clarity, use lflags, a local copy of gcnf.flags, throughout when
dealing with the requested flags, rather than a mixture of both.

Fixes: e588bb1eae31 ("gpio: add new SET_CONFIG ioctl() to gpio chardev")
Signed-off-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: Cleanup kfifo_out() error handling

The handling of kfifo_out() errors in read functions obscures any error.
The error condition should never occur but, while a ret is set to -EIO, it

gpiolib: cdev: Cleanup kfifo_out() error handling

The handling of kfifo_out() errors in read functions obscures any error.
The error condition should never occur but, while a ret is set to -EIO, it
is subsequently ignored and the read functions instead return the number
of bytes copied to that point, potentially masking the fact that any error
occurred.

Log a warning and return -EIO in the case of a kfifo_out() error to make
it clear something very odd is going on here.

Signed-off-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: Refactor allocation of linereq events kfifo

The allocation of the linereq events kfifo is performed in two separate
places. Add a helper function to remove the duplication.

Signed-o

gpiolib: cdev: Refactor allocation of linereq events kfifo

The allocation of the linereq events kfifo is performed in two separate
places. Add a helper function to remove the duplication.

Signed-off-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: Add INIT_KFIFO() for linereq events

The initialisation of the linereq events kfifo relies on the struct being
zeroed and a subsequent call to kfifo_alloc(). The call to kfifo_alloc()

gpiolib: cdev: Add INIT_KFIFO() for linereq events

The initialisation of the linereq events kfifo relies on the struct being
zeroed and a subsequent call to kfifo_alloc(). The call to kfifo_alloc()
is deferred until edge detection is first enabled for the linereq. If the
kfifo is inadvertently accessed before the call to kfifo_alloc(), as was
the case in a recently discovered bug, it behaves as a FIFO of size 1 with
an element size of 0, so writes and reads to the kfifo appear successful
but copy no actual data.

As a defensive measure, initialise the kfifo with INIT_KFIFO() when the
events kfifo is constructed. This initialises the kfifo element size
and zeroes its data pointer, so any inadvertant access prior to the
kfifo_alloc() call will trigger an oops.

Signed-off-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: fix uninitialised kfifo

If a line is requested with debounce, and that results in debouncing
in software, and the line is subsequently reconfigured to enable edge
detection then the a

gpiolib: cdev: fix uninitialised kfifo

If a line is requested with debounce, and that results in debouncing
in software, and the line is subsequently reconfigured to enable edge
detection then the allocation of the kfifo to contain edge events is
overlooked. This results in events being written to and read from an
uninitialised kfifo. Read events are returned to userspace.

Initialise the kfifo in the case where the software debounce is
already active.

Fixes: 65cff7046406 ("gpiolib: cdev: support setting debounce")
Signed-off-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: cdev: Fix use after free in lineinfo_changed_notify

The use-after-free issue occurs as follows: when the GPIO chip device file
is being closed by invoking gpio_chrdev_release(), watched_lin

gpiolib: cdev: Fix use after free in lineinfo_changed_notify

The use-after-free issue occurs as follows: when the GPIO chip device file
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
chain failed due to waiting write rwsem. Additionally, one of the GPIO
chip's lines is also in the release process and holds the notifier chain's
read rwsem. Consequently, a race condition leads to the use-after-free of
watched_lines.

Here is the typical stack when issue happened:

[free]
gpio_chrdev_release()
--> bitmap_free(cdev->watched_lines) <-- freed
--> blocking_notifier_chain_unregister()
--> down_write(&nh->rwsem) <-- waiting rwsem
--> __down_write_common()
--> rwsem_down_write_slowpath()
--> schedule_preempt_disabled()
--> schedule()

[use]
st54spi_gpio_dev_release()
--> gpio_free()
--> gpiod_free()
--> gpiod_free_commit()
--> gpiod_line_state_notify()
--> blocking_notifier_call_chain()
--> down_read(&nh->rwsem); <-- held rwsem
--> notifier_call_chain()
--> lineinfo_changed_notify()
--> test_bit(xxxx, cdev->watched_lines) <-- use after free

The side effect of the use-after-free issue is that a GPIO line event is
being generated for userspace where it shouldn't. However, since the chrdev
is being closed, userspace won't have the chance to read that event anyway.

To fix the issue, call the bitmap_free() function after the unregistration
of lineinfo_changed_nb notifier chain.

Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info")
Signed-off-by: Zhongqiu Han <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: use a single SRCU struct for all GPIO descriptors

We used a per-descriptor SRCU struct in order to not impose a wait with
synchronize_srcu() for descriptor X on read-only operations of
desc

gpiolib: use a single SRCU struct for all GPIO descriptors

We used a per-descriptor SRCU struct in order to not impose a wait with
synchronize_srcu() for descriptor X on read-only operations of
descriptor Y. Now that we no longer call synchronize_srcu() on
descriptor label change but only when releasing descriptor resources, we
can use a single SRCU structure for all GPIO descriptors in a given chip.

Suggested-by: "Paul E. McKenney" <[email protected]>
Acked-by: "Paul E. McKenney" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: cdev: fix missed label sanitizing in debounce_setup()

When adding sanitization of the label, the path through
edge_detector_setup() that leads to debounce_setup() was overlooked.
A request tak

gpio: cdev: fix missed label sanitizing in debounce_setup()

When adding sanitization of the label, the path through
edge_detector_setup() that leads to debounce_setup() was overlooked.
A request taking this path does not allocate a new label and the
request label is freed twice when the request is released, resulting
in memory corruption.

Add label sanitization to debounce_setup().

Cc: [email protected]
Fixes: b34490879baa ("gpio: cdev: sanitize the label before requesting the interrupt")
Signed-off-by: Kent Gibson <[email protected]>
[Bartosz: rebased on top of the fix for empty GPIO labels]
Co-developed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: cdev: check for NULL labels when sanitizing them for irqs

We need to take into account that a line's consumer label may be NULL
and not try to kstrdup() it in that case but rather pass the NUL

gpio: cdev: check for NULL labels when sanitizing them for irqs

We need to take into account that a line's consumer label may be NULL
and not try to kstrdup() it in that case but rather pass the NULL
pointer up the stack to the interrupt request function.

To that end: let make_irq_label() return NULL as a valid return value
and use ERR_PTR() instead to signal an allocation failure to callers.

Cc: [email protected]
Fixes: b34490879baa ("gpio: cdev: sanitize the label before requesting the interrupt")
Reported-by: Linux Kernel Functional Testing <[email protected]>
Closes: https://lore.kernel.org/lkml/[email protected]/
Signed-off-by: Bartosz Golaszewski <[email protected]>
Tested-by: Anders Roxell <[email protected]>

show more ...