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 <[email protected]> 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 <[email protected]> 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/[email protected]/. The replacement still brings a few overhead (e.g., for allocating some in the .open() file operations). Especially the test approach can accumulate them.
