On Sat, Jan 24, 2026 at 05:52:53PM +0100, Johan Hovold wrote: > On Fri, Jan 16, 2026 at 08:10:35AM +0000, Tzung-Bi Shih wrote: > > There are independent lifecycle instances (e.g., other drivers) can save > > a raw pointer to the struct gpio_device (e.g., via gpio_device_find()) > > or struct gpio_desc (e.g., via gpio_to_desc()). In some operations, > > they have to access the underlying struct gpio_chip. > > > > Leverage revocable for them so that they don't need to handle the > > synchronization by accessing the SRCU explicitly. > > > > Signed-off-by: Tzung-Bi Shih <[email protected]> > > > static int gpiod_get_raw_value_commit(const struct gpio_desc *desc) > > { > > - struct gpio_device *gdev; > > struct gpio_chip *gc; > > int value; > > + DEFINE_REVOCABLE(rev, desc->gdev->chip_rp); > > DEFINE_REVOCABLE() is racy and can lead to use-after-free since nothing > prevents chip_rp from being revoked and freed while the > revocable_alloc() hidden in DEFINE_REVOCABLE() is running.
This was supposed to say "revocable_init()" (i.e. revocable_alloc() without the memory allocation). > > > > - /* FIXME Unable to use gpio_chip_guard due to const desc. */ > > - gdev = desc->gdev; > > - > > - guard(srcu)(&gdev->srcu); > > - > > - gc = srcu_dereference(gdev->chip, &gdev->srcu); > > + REVOCABLE_TRY_ACCESS_WITH(rev, gc); > > if (!gc) > > return -ENODEV; Johan
