On Mon, Jan 26, 2026 at 02:58:17PM +0100, Johan Hovold wrote:
> 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).

I see the issue.  Thanks for identifying this.

Reply via email to