This series transitions the UAF prevention logic within the GPIO core
(gpiolib) to use the 'revocable' mechanism.

The existing code aims to prevent UAF issues when the underlying GPIO
chip is removed.  This series replaces that custom logic with the
generic 'revocable' API, which is designed to handle such lifecycle
dependencies.  There should be no change in behavior.

This series depends on the 'revocable' API, introduced in [1].  Some
build bots may report errors due to undefined symbols related to
'revocable' until the dependency is merged.

[1] https://lore.kernel.org/chrome-platform/20260116080235.350305-1-tzungbi@kernel.org

Tzung-Bi Shih (23):
  gpiolib: Correct wrong kfree() usage for `kobj->name`
  gpiolib: cdev: Fix resource leaks on errors in gpiolib_cdev_register()
  gpiolib: Fix resource leaks on errors in gpiochip_add_data_with_key()
  gpiolib: Fix resource leaks on errors in lineinfo_changed_notify()
  gpiolib: cdev: Correct return code on memory allocation failure

=> The first 5 patches are fixes.  They aren't directly related to the
   replacement, and should be able to apply independently.

  gpiolib: Access `gpio_bus_type` in gpiochip_setup_dev()
  gpiolib: Remove redundant check for struct gpio_chip
  gpiolib: sysfs: Remove redundant check for struct gpio_chip
  gpiolib: Ensure struct gpio_chip for gpiochip_setup_dev()
  gpiolib: cdev: Don't check struct gpio_chip in gpio_chrdev_open()

=> The following 5 patches are refactors.  Makes the subsequent changes
   easier or at least clear.

  selftests: gpio: Add gpio-cdev-uaf tests

=> The following patch adds kselftest cases for some classic UAF
   scenarios.

  gpiolib: Add revocable provider handle for struct gpio_chip
  gpiolib: cdev: Leverage revocable for gpio_fileops
  gpiolib: cdev: Leverage revocable for linehandle_fileops
  gpiolib: cdev: Leverage revocable for line_fileops
  gpiolib: cdev: Leverage revocable for lineevent_fileops
  gpiolib: cdev: Leverage revocable for lineinfo_changed_notify
  gpiolib: Leverage revocable for gpiolib_sops

=> The following 7 patches start to replace the existing code.  They
   are intentionally making small changes for easier to review.

  revocable: Support to define revocable consumer handle on stack
  revocable: Add Kunit test case for DEFINE_REVOCABLE()
  selftests: revocable: Add test case for DEFINE_REVOCABLE()

=> The following 3 patches introduce a new way to define revocable
   consumer handles on stack and its test cases.

  gpiolib: Leverage revocable for other independent lifecycle instances

=> The following patch handles the "others" (i.e., the rest of those
   custom logic) by using DEFINE_REVOCABLE() to at least make the usage
   easier.  A big patch.

  gpiolib: Remove unused `chip` and `srcu` in struct gpio_device

=> The last patch removes the unused fields for the custom logic as all
   of them should be transiting to revocable.

 .../driver-api/driver-model/revocable.rst     |   5 +-
 drivers/base/revocable.c                      |  60 ++-
 drivers/base/revocable_test.c                 |  54 +++
 drivers/gpio/gpiolib-cdev.c                   | 262 ++++++-----
 drivers/gpio/gpiolib-cdev.h                   |   3 +-
 drivers/gpio/gpiolib-sysfs.c                  |  55 ++-
 drivers/gpio/gpiolib-sysfs.h                  |  11 +-
 drivers/gpio/gpiolib.c                        | 410 ++++++++++--------
 drivers/gpio/gpiolib.h                        |  27 +-
 include/linux/revocable.h                     |  30 +-
 .../drivers/base/revocable/revocable_test.c   |  12 +
 .../revocable/test_modules/revocable_test.c   |  37 +-
 tools/testing/selftests/gpio/Makefile         |   5 +-
 tools/testing/selftests/gpio/gpio-cdev-uaf.c  | 320 ++++++++++++++
 tools/testing/selftests/gpio/gpio-cdev-uaf.sh |  67 +++
 15 files changed, 974 insertions(+), 384 deletions(-)
 create mode 100644 tools/testing/selftests/gpio/gpio-cdev-uaf.c
 create mode 100755 tools/testing/selftests/gpio/gpio-cdev-uaf.sh

-- 
2.52.0.457.g6b5491de43-goog

On Fri, Jan 16, 2026 at 9:11 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>
> This series transitions the UAF prevention logic within the GPIO core
> (gpiolib) to use the 'revocable' mechanism.
>
> The existing code aims to prevent UAF issues when the underlying GPIO
> chip is removed.  This series replaces that custom logic with the
> generic 'revocable' API, which is designed to handle such lifecycle
> dependencies.  There should be no change in behavior.
>
> This series depends on the 'revocable' API, introduced in [1].  Some
> build bots may report errors due to undefined symbols related to
> 'revocable' until the dependency is merged.
>

Hi Tzung-Bi!

Thank you for doing this and considering my suggestions from LPC. I
haven't looked at the code yet but I quickly tested the series with my
regular test-suites. The good news is: nothing is broken, every test
works fine. The bad news is: there seems to be a significant impact on
performance. With the user-space test-suite from libgpiod (for core C
library - gpiod-test) I'm seeing a consistent 40% impact on
performance. That's not really acceptable. :( I will try to bisect the
series later and see which part exactly breaks it.

I can also help you with user-space testing with libgpiod, if you need
it? Some documentation is available here:
https://libgpiod.readthedocs.io/en/latest/testing.html

> [1] https://lore.kernel.org/chrome-platform/20260116080235.350305-1-tzungbi@kernel.org
>
> Tzung-Bi Shih (23):
>   gpiolib: Correct wrong kfree() usage for `kobj->name`
>   gpiolib: cdev: Fix resource leaks on errors in gpiolib_cdev_register()
>   gpiolib: Fix resource leaks on errors in gpiochip_add_data_with_key()
>   gpiolib: Fix resource leaks on errors in lineinfo_changed_notify()
>   gpiolib: cdev: Correct return code on memory allocation failure
>
> => The first 5 patches are fixes.  They aren't directly related to the
>    replacement, and should be able to apply independently.
>

Awesome, I'll make them a priority.

>   gpiolib: Access `gpio_bus_type` in gpiochip_setup_dev()
>   gpiolib: Remove redundant check for struct gpio_chip
>   gpiolib: sysfs: Remove redundant check for struct gpio_chip
>   gpiolib: Ensure struct gpio_chip for gpiochip_setup_dev()
>   gpiolib: cdev: Don't check struct gpio_chip in gpio_chrdev_open()
>
> => The following 5 patches are refactors.  Makes the subsequent changes
>    easier or at least clear.
>
>   selftests: gpio: Add gpio-cdev-uaf tests
>
> => The following patch adds kselftest cases for some classic UAF
>    scenarios.
>

Thanks, these too look like v7.0 material for me. I'll try to review
these ASAP too.

Bart

On Fri, Jan 16, 2026 at 11:35:00AM +0100, Bartosz Golaszewski wrote:
> On Fri, Jan 16, 2026 at 9:11 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >
> > This series transitions the UAF prevention logic within the GPIO core
> > (gpiolib) to use the 'revocable' mechanism.
> >
> > The existing code aims to prevent UAF issues when the underlying GPIO
> > chip is removed.  This series replaces that custom logic with the
> > generic 'revocable' API, which is designed to handle such lifecycle
> > dependencies.  There should be no change in behavior.
> >
> > This series depends on the 'revocable' API, introduced in [1].  Some
> > build bots may report errors due to undefined symbols related to
> > 'revocable' until the dependency is merged.
> >
> 
> Hi Tzung-Bi!
> 
> Thank you for doing this and considering my suggestions from LPC. I
> haven't looked at the code yet but I quickly tested the series with my
> regular test-suites. The good news is: nothing is broken, every test
> works fine. The bad news is: there seems to be a significant impact on
> performance. With the user-space test-suite from libgpiod (for core C
> library - gpiod-test) I'm seeing a consistent 40% impact on
> performance. That's not really acceptable. :( I will try to bisect the
> series later and see which part exactly breaks it.
> 
> I can also help you with user-space testing with libgpiod, if you need
> it? Some documentation is available here:
> https://libgpiod.readthedocs.io/en/latest/testing.html

How to get the performance data?

I tried on libgpiod-2.2.2.tar.xz:
- ./configure --enable-tools --enable-tests
- make
- ./tests/gpiod-test

There is only TAP output.  Also I don't see the difference between:
`./tests/gpiod-test` vs. `./tests/gpiod-test -m perf`.

On Sat, Jan 17, 2026 at 1:48 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>
> On Fri, Jan 16, 2026 at 11:35:00AM +0100, Bartosz Golaszewski wrote:
> > On Fri, Jan 16, 2026 at 9:11 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> > >
> > > This series transitions the UAF prevention logic within the GPIO core
> > > (gpiolib) to use the 'revocable' mechanism.
> > >
> > > The existing code aims to prevent UAF issues when the underlying GPIO
> > > chip is removed.  This series replaces that custom logic with the
> > > generic 'revocable' API, which is designed to handle such lifecycle
> > > dependencies.  There should be no change in behavior.
> > >
> > > This series depends on the 'revocable' API, introduced in [1].  Some
> > > build bots may report errors due to undefined symbols related to
> > > 'revocable' until the dependency is merged.
> > >
> >
> > Hi Tzung-Bi!
> >
> > Thank you for doing this and considering my suggestions from LPC. I
> > haven't looked at the code yet but I quickly tested the series with my
> > regular test-suites. The good news is: nothing is broken, every test
> > works fine. The bad news is: there seems to be a significant impact on
> > performance. With the user-space test-suite from libgpiod (for core C
> > library - gpiod-test) I'm seeing a consistent 40% impact on
> > performance. That's not really acceptable. :( I will try to bisect the
> > series later and see which part exactly breaks it.
> >
> > I can also help you with user-space testing with libgpiod, if you need
> > it? Some documentation is available here:
> > https://libgpiod.readthedocs.io/en/latest/testing.html
>
> How to get the performance data?
>
> I tried on libgpiod-2.2.2.tar.xz:
> - ./configure --enable-tools --enable-tests
> - make
> - ./tests/gpiod-test
>
> There is only TAP output.  Also I don't see the difference between:
> `./tests/gpiod-test` vs. `./tests/gpiod-test -m perf`.

Yeah, no, there's no dedicated performance measurement in GLib tests,
I just timed the test-suite and it runs 40% slower with this series.

Bartosz

On Mon, Jan 19, 2026 at 09:33:21AM +0100, Bartosz Golaszewski wrote:
> On Sat, Jan 17, 2026 at 1:48 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >
> > On Fri, Jan 16, 2026 at 11:35:00AM +0100, Bartosz Golaszewski wrote:
> > > On Fri, Jan 16, 2026 at 9:11 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> > > >
> > > > This series transitions the UAF prevention logic within the GPIO core
> > > > (gpiolib) to use the 'revocable' mechanism.
> > > >
> > > > The existing code aims to prevent UAF issues when the underlying GPIO
> > > > chip is removed.  This series replaces that custom logic with the
> > > > generic 'revocable' API, which is designed to handle such lifecycle
> > > > dependencies.  There should be no change in behavior.
> > > >
> > > > This series depends on the 'revocable' API, introduced in [1].  Some
> > > > build bots may report errors due to undefined symbols related to
> > > > 'revocable' until the dependency is merged.
> > > >
> > >
> > > Hi Tzung-Bi!
> > >
> > > Thank you for doing this and considering my suggestions from LPC. I
> > > haven't looked at the code yet but I quickly tested the series with my
> > > regular test-suites. The good news is: nothing is broken, every test
> > > works fine. The bad news is: there seems to be a significant impact on
> > > performance. With the user-space test-suite from libgpiod (for core C
> > > library - gpiod-test) I'm seeing a consistent 40% impact on
> > > performance. That's not really acceptable. :( I will try to bisect the
> > > series later and see which part exactly breaks it.
> > >
> > > I can also help you with user-space testing with libgpiod, if you need
> > > it? Some documentation is available here:
> > > https://libgpiod.readthedocs.io/en/latest/testing.html
> >
> > How to get the performance data?
> >
> > I tried on libgpiod-2.2.2.tar.xz:
> > - ./configure --enable-tools --enable-tests
> > - make
> > - ./tests/gpiod-test
> >
> > There is only TAP output.  Also I don't see the difference between:
> > `./tests/gpiod-test` vs. `./tests/gpiod-test -m perf`.
> 
> Yeah, no, there's no dedicated performance measurement in GLib tests,
> I just timed the test-suite and it runs 40% slower with this series.

I think this is mostly introduced by a redundant synchronize_srcu() call in
revocable_provider_alloc().  Proposed a fix in
https://lore.kernel.org/all/20260121040204.2699886-1-tzungbi@kernel.org/.

The replacement still brings a few overhead (e.g., for allocating some in
the .open() file operations).  Especially the test approach can accumulate
them.

On Wed, Jan 21, 2026 at 5:17 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>
> On Mon, Jan 19, 2026 at 09:33:21AM +0100, Bartosz Golaszewski wrote:
> > On Sat, Jan 17, 2026 at 1:48 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> > >
> > > On Fri, Jan 16, 2026 at 11:35:00AM +0100, Bartosz Golaszewski wrote:
> > > > On Fri, Jan 16, 2026 at 9:11 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> > > > >
> > > > > This series transitions the UAF prevention logic within the GPIO core
> > > > > (gpiolib) to use the 'revocable' mechanism.
> > > > >
> > > > > The existing code aims to prevent UAF issues when the underlying GPIO
> > > > > chip is removed.  This series replaces that custom logic with the
> > > > > generic 'revocable' API, which is designed to handle such lifecycle
> > > > > dependencies.  There should be no change in behavior.
> > > > >
> > > > > This series depends on the 'revocable' API, introduced in [1].  Some
> > > > > build bots may report errors due to undefined symbols related to
> > > > > 'revocable' until the dependency is merged.
> > > > >
> > > >
> > > > Hi Tzung-Bi!
> > > >
> > > > Thank you for doing this and considering my suggestions from LPC. I
> > > > haven't looked at the code yet but I quickly tested the series with my
> > > > regular test-suites. The good news is: nothing is broken, every test
> > > > works fine. The bad news is: there seems to be a significant impact on
> > > > performance. With the user-space test-suite from libgpiod (for core C
> > > > library - gpiod-test) I'm seeing a consistent 40% impact on
> > > > performance. That's not really acceptable. :( I will try to bisect the
> > > > series later and see which part exactly breaks it.
> > > >
> > > > I can also help you with user-space testing with libgpiod, if you need
> > > > it? Some documentation is available here:
> > > > https://libgpiod.readthedocs.io/en/latest/testing.html
> > >
> > > How to get the performance data?
> > >
> > > I tried on libgpiod-2.2.2.tar.xz:
> > > - ./configure --enable-tools --enable-tests
> > > - make
> > > - ./tests/gpiod-test
> > >
> > > There is only TAP output.  Also I don't see the difference between:
> > > `./tests/gpiod-test` vs. `./tests/gpiod-test -m perf`.
> >
> > Yeah, no, there's no dedicated performance measurement in GLib tests,
> > I just timed the test-suite and it runs 40% slower with this series.
>
> I think this is mostly introduced by a redundant synchronize_srcu() call in
> revocable_provider_alloc().  Proposed a fix in
> https://lore.kernel.org/all/20260121040204.2699886-1-tzungbi@kernel.org/.
>
> The replacement still brings a few overhead (e.g., for allocating some in
> the .open() file operations).  Especially the test approach can accumulate
> them.

People do care about open()/close() performance, please see the
following discussion:
https://lore.kernel.org/all/20250311110034.53959031@erd003.prtnl/

It required us to use raw notifiers instead of atomic ones which call
rcu_synchronize() to fix the performance regression.

Bartosz

On Fri, Jan 16, 2026 at 11:35:00AM +0100, Bartosz Golaszewski wrote:
> On Fri, Jan 16, 2026 at 9:11 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >
> > This series transitions the UAF prevention logic within the GPIO core
> > (gpiolib) to use the 'revocable' mechanism.
> >
> > The existing code aims to prevent UAF issues when the underlying GPIO
> > chip is removed.  This series replaces that custom logic with the
> > generic 'revocable' API, which is designed to handle such lifecycle
> > dependencies.  There should be no change in behavior.
> >
> > This series depends on the 'revocable' API, introduced in [1].  Some
> > build bots may report errors due to undefined symbols related to
> > 'revocable' until the dependency is merged.
> >
> 
> Hi Tzung-Bi!
> 
> Thank you for doing this and considering my suggestions from LPC. I
> haven't looked at the code yet but I quickly tested the series with my
> regular test-suites. The good news is: nothing is broken, every test
> works fine. The bad news is: there seems to be a significant impact on
> performance. With the user-space test-suite from libgpiod (for core C
> library - gpiod-test) I'm seeing a consistent 40% impact on
> performance. That's not really acceptable. :( I will try to bisect the
> series later and see which part exactly breaks it.

Also, as discussed during LPC, revocable is not the right mechanism to
handle races between device removal and userspace access through cdev.
It could however be a good tool to handle races between producers and
consumers inside the kernel. I'll try to review this series to see if it
also addresses the latter.

> I can also help you with user-space testing with libgpiod, if you need
> it? Some documentation is available here:
> https://libgpiod.readthedocs.io/en/latest/testing.html
> 
> > [1] https://lore.kernel.org/chrome-platform/20260116080235.350305-1-tzungbi@kernel.org
> >
> > Tzung-Bi Shih (23):
> >   gpiolib: Correct wrong kfree() usage for `kobj->name`
> >   gpiolib: cdev: Fix resource leaks on errors in gpiolib_cdev_register()
> >   gpiolib: Fix resource leaks on errors in gpiochip_add_data_with_key()
> >   gpiolib: Fix resource leaks on errors in lineinfo_changed_notify()
> >   gpiolib: cdev: Correct return code on memory allocation failure
> >
> > => The first 5 patches are fixes.  They aren't directly related to the
> >    replacement, and should be able to apply independently.
> >
> 
> Awesome, I'll make them a priority.
> 
> >   gpiolib: Access `gpio_bus_type` in gpiochip_setup_dev()
> >   gpiolib: Remove redundant check for struct gpio_chip
> >   gpiolib: sysfs: Remove redundant check for struct gpio_chip
> >   gpiolib: Ensure struct gpio_chip for gpiochip_setup_dev()
> >   gpiolib: cdev: Don't check struct gpio_chip in gpio_chrdev_open()
> >
> > => The following 5 patches are refactors.  Makes the subsequent changes
> >    easier or at least clear.
> >
> >   selftests: gpio: Add gpio-cdev-uaf tests
> >
> > => The following patch adds kselftest cases for some classic UAF
> >    scenarios.
> >
> 
> Thanks, these too look like v7.0 material for me. I'll try to review
> these ASAP too.

-- 
Regards,

Laurent Pinchart

On Fri, 16 Jan 2026 08:10:13 +0000, Tzung-Bi Shih wrote:
> This series transitions the UAF prevention logic within the GPIO core
> (gpiolib) to use the 'revocable' mechanism.
> 
> The existing code aims to prevent UAF issues when the underlying GPIO
> chip is removed.  This series replaces that custom logic with the
> generic 'revocable' API, which is designed to handle such lifecycle
> dependencies.  There should be no change in behavior.
> 
> [...]

Tzung-Bi: I queued these two for fixes. Please resend patch 04/23 separately
so that I can queue it for v6.19 as well. 01/23 and 03/23 risk impacting a
very fragile path in GPIOLIB so any changes to it will have to wait until
v7.0-rc1 to give it a lot of time in next.

[02/23] gpiolib: cdev: Fix resource leaks on errors in gpiolib_cdev_register()
        commit: be037ec1785d76351037103ce6baddd3299606ee
[05/23] gpiolib: cdev: Correct return code on memory allocation failure
        commit: c7843298bf973d4bc7f4346140661e117186decc

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

On Mon, Jan 19, 2026 at 03:21:30PM +0100, Bartosz Golaszewski wrote:
> Tzung-Bi: I queued these two for fixes. Please resend patch 04/23 separately
> so that I can queue it for v6.19 as well. 01/23 and 03/23 risk impacting a
> very fragile path in GPIOLIB so any changes to it will have to wait until
> v7.0-rc1 to give it a lot of time in next.
> 
> [02/23] gpiolib: cdev: Fix resource leaks on errors in gpiolib_cdev_register()
>         commit: be037ec1785d76351037103ce6baddd3299606ee
> [05/23] gpiolib: cdev: Correct return code on memory allocation failure
>         commit: c7843298bf973d4bc7f4346140661e117186decc

v2 of [04/23]: https://lore.kernel.org/all/20260120030857.2144847-1-tzungbi@kernel.org