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. Bartosz
