>
> I don't think it's a bug. The unregister loop only goes up to the
> number of registered ->num_leds. num_leds is only incremented if we
> register successfully.
>
> regards,
> dan carpenter
Oops, I may have had a wrong explanation for what I still believe is a real bug.
I apologize for explaining it in incorrectly. I had it written down differently
in my notes but somehow screwed up when actually reporting it.
Here is a slightly different sequence of events -- most is the same:
- Suppose sysfs_create_group (line 860 in leds-lp5523.c in latest kernel) in
lp5523_init_led fails.
- Control takes the error path:
862 if (res < 0) {
863 dev_err(dev, "couldn't register current attribute\n");
864 led_classdev_unregister(&led->cdev);
865 return res;
866 }
- In this failure case, the INIT_WORK macro is not yet called for this LED.
This normally executes in the same for() loop that calls lp5523_init_led, line
959, which is after the call to lp5523_init_led returns.
- So, when we we call led_classdev_unregister on line 864 (from
lp5523_init_led), this invokes led_brightness_set, and in turn calls
lp5523_set_brightness, which then calls schedule_work on the uninitialized work
queue. This can panic the kernel.
I hope that makes sense. I apologize again for screwing it up the first time.
Thanks and regards,
Matt
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
