[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260116160729.GB14499@pendragon.ideasonboard.com>
Date: Fri, 16 Jan 2026 18:07:29 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Bartosz Golaszewski <brgl@...nel.org>
Cc: Tzung-Bi Shih <tzungbi@...nel.org>, Benson Leung <bleung@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>,
Linus Walleij <linusw@...nel.org>, Jonathan Corbet <corbet@....net>,
Shuah Khan <shuah@...nel.org>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev,
linux-kselftest@...r.kernel.org,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Simona Vetter <simona.vetter@...ll.ch>,
Dan Williams <dan.j.williams@...el.com>,
Jason Gunthorpe <jgg@...dia.com>, linux-gpio@...r.kernel.org
Subject: Re: [PATCH 00/23] gpiolib: Adopt revocable mechanism for UAF
prevention
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@...nel.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
Powered by blists - more mailing lists