Re: [PATCH 0/2] gpio: core: fix const-correctness and remove UAF FIXMEs

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Sun, May 24, 2026 at 06:27:06PM +0200, Marco Scardovi (scardracs) wrote:
> This series addresses legacy "FIXME Cannot use gpio_chip_guard due to
> const desc" comments and open-coded SRCU locks scattered throughout the
> gpiolib core and backend lookup paths.
> 
> I am aware of the ongoing work to replace the gpio_chip_guard architecture
> entirely (see the "revocable objects" patchset discussion at
> https://lore.kernel.org/linux-gpio/20260513091043.6766-1-tzungbi@kernel.org/).
> While that broader refactoring is being iterated upon, this patch series
> provides a simple, completely type-safe fix utilizing the existing SRCU
> guard infrastructure. It can be merged today to eliminate the FIXMEs
> without conflicting conceptually with future revocable objects.

Sounds reasonable to me and the code looks good, but I haven't deeply checked that.
Hence
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

and personally I very much like the second patch and agree that it's good to
have rather sooner in tree in case the change is correct.

But we anyway need to know Bart's take on this.

> For clarity during review, the series relies on the following guarantees:
> 
> 1. Deep Const-Correctness is Preserved:
> Updating DEFINE_CLASS(gpio_chip_guard, ...) to accept a `const struct
> gpio_desc *desc` does not drop const qualifiers. In C, const-propagation
> does not implicitly const-qualify deep pointers. The `desc->gdev` evaluation
> yields a mutable `struct gpio_device *`, making the internal guard
> assignment perfectly legal and safe for fast-path read operations.
> 
> 2. Identical SRCU Lifetime Scope:
> The DEFINE_CLASS macro's GNU C compound statement `({ ... })` relies
> on strict sequence points. Thus, `srcu_read_lock()` is fully acquired
> prior to executing `srcu_dereference()`. The guard's lifetime remains
> identically bound to the block scope, exactly mirroring the open-coded
> `guard(srcu)(&gdev->srcu)` it replaces.
> 
> 3. Lookup UAF FIXMEs are Architecturally Obsolete:
> The FIXME comments removed in the ACPI and swnode backend lookup paths
> (warning about dropping the device reference) are functionally obsolete.
> By design, `gpiod_find_and_request()` wraps the entire backend lookup
> operation inside the global `gpio_devices_srcu` read lock. The lookup
> functions are entirely safe to drop their temporary references since the
> caller subsequently takes its own permanent references without ever leaving
> the SRCU read-side critical section.
> 
> Please note that while this patch provides a good solution to clean up the
> existing codebase, I fully understand the necessity of deeper and more
> radical modifications to robustly secure the subsystem's future.

-- 
With Best Regards,
Andy Shevchenko