On Wed, Apr 29, 2015 at 11:44:18PM +0200, Linus Walleij wrote: > On Tue, Apr 21, 2015 at 5:42 PM, Johan Hovold <johan@xxxxxxxxxx> wrote: > > > Unregister GPIOs requested through sysfs at chip remove to avoid leaking > > the associated memory and sysfs entries. > > > > The stale sysfs entries prevented the gpio numbers from being exported > > when the gpio range was later reused (e.g. at device reconnect). > > > > This also fixes the related module-reference leak. > > > > Note that kernfs makes sure that any on-going sysfs operations finish > > before the class devices are unregistered and that further accesses > > fail. > > > > The chip exported flag is used to prevent gpiod exports during removal. > > This also makes it harder to trigger, but does not fix, the related race > > between gpiochip_remove and export_store, which is really a race with > > gpiod_request that needs to be addressed separately. > > > > Also note that this would prevent the crashes (e.g. NULL-dereferences) > > at reconnect that affects pre-3.18 kernels, as well as use-after-free on > > operations on open attribute files on pre-3.14 kernels (prior to > > kernfs). > > > > Fixes: d8f388d8dc8d ("gpio: sysfs interface") > > Cc: stable <stable@xxxxxxxxxxxxxxx> # v2.6.27: 01cca93a9491 > > Signed-off-by: Johan Hovold <johan@xxxxxxxxxx> > > Patch applied for fixes. > > I worry a bit about what userspaces do out there, but they > cannot reasonably have behaviours tied to in-flight removal > of GPIO chips, that would be bizarre. You shouldn't worry too much; even before this patch userspace would see an -ENODEV when accessing an open sysfs attribute file of a disconnected device as kernfs would orphan the file -- only now without the associated leaks and crashes. ;) Johan -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html