On Tue, Jun 7, 2016 at 5:29 PM, Grygorii Strashko <grygorii.strashko@xxxxxx> wrote: > On 06/07/2016 04:33 PM, Linus Walleij wrote: >> On Tue, Jun 7, 2016 at 9:50 AM, Roger Quadros <rogerq@xxxxxx> wrote: >> >>> Linus, any idea why of_gpiochip_find_and_xlate() would do a NULL pointer dereference? >> >> Nope. I see this uses the array fetch function which I did patch around but >> "should" not affect this. >> >>> We have a case here where the GPMC driver registers a gpiochip but after a while >>> unregisters it due to some other orthogonal resource not being available. >>> Is this registering and unregistering considered acceptable from gpiochip point of view? >> >> That would be if it doesn't really go away aftert gpiochip_remove() because >> some refcount doesn't go zero, so double-check that. It should be fine >> anyway though ... just the instance floating around somewhere. >> > > Linus, I've tried to find place in gpiolib.c where gpiochip is removed > from gpio_devices list as part of gpiochip_remove(), but I can't. Am I missed smth.? It is supposed to happen in gpiodevice_release() as an effect of the references to the kobject in the device going to zero when the last put_device() is called in gpiochip_remove(). Unless there is already some other user that has taken a descriptor, such as a kernel driver or userspace. > If that is the case then such kind of crash is possible, because gpiochip_find() > uses this list. Hm I suspect it could be that the reference count is off, so the device isn't removed from the list? But we should still numb the device somehow so that the crash doesn't happen even if the device is still in the list. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
