On Tue, Nov 29, 2022 at 06:53:26PM +0200, Andy Shevchenko wrote: > On Tue, Nov 29, 2022 at 01:35:53PM +0100, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > While any of the GPIO cdev syscalls is in progress, the kernel can call > > gpiochip_remove() (for instance, when a USB GPIO expander is disconnected) > > which will set gdev->chip to NULL after which any subsequent access will > > cause a crash. > > > > To avoid that: use an RW-semaphore in which the syscalls take it for > > reading (so that we don't needlessly prohibit the user-space from calling > > syscalls simultaneously) while gpiochip_remove() takes it for writing so > > that it can only happen once all syscalls return. > > ... > > I would do > > typedef __poll_t (*poll_fn)(struct file *, struct poll_table_struct *); > > and so on and use that one in the respective parameters. > > BUT. Since it's a fix, up to you which one to choose. > FWIW, the typedef looks cleaner to me too. > > +static __poll_t call_poll_locked(struct file *file, > > + struct poll_table_struct *wait, > > + struct gpio_device *gdev, > > + __poll_t (*func)(struct file *, > > + struct poll_table_struct *)) > > +{ > > + __poll_t ret; > > + > > + down_read(&gdev->sem); > > + ret = func(file, wait); > > + up_read(&gdev->sem); > > + > > + return ret; > > +} > > ... > > > + down_write(&gdev->sem); > > + Blank line? > Agreed. > > /* FIXME: should the legacy sysfs handling be moved to gpio_device? */ > > gpiochip_sysfs_unregister(gdev); > > gpiochip_free_hogs(gc); > > ... > > > gcdev_unregister(gdev); > > + Blank line ? > Disagree with this one though. The comment prior to the gcdev_unregister() appears to apply to the block, so the following lines should remain grouped. Other than those nits, the series looks good to me. Reviewed-by: Kent Gibson <warthog618@xxxxxxxxx> Cheers, Kent. > > + up_write(&gdev->sem); > > put_device(&gdev->dev); > > -- > With Best Regards, > Andy Shevchenko > >