Potential initialization bug in leds-lp5523

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I'm writing to report a potential bug in this driver.  I don't have a patch as
I'm unsure the best way to fix it.  The error, which can lead to a kernel panic,
is as follows:

- Suppose sysfs_create_group (line 860 in leds-lp5523.c in latest kernel) in
lp5523_init_led fails.  The function will return early with an error code as a
result.
- Control returns to lp5523_probe, and breaks out of the loop to the fail3
label.
- In this failure case, the INIT_WORK macro is never called for this LED.  This
normally executes in the same for() loop that calls lp5523_init_led, line 959,
but because of the failure, the loop breaks execution early.
- Execution continues with the cleanup loop:

        for (i = 0; i < chip->num_leds; i++) {
                led_classdev_unregister(&chip->leds[i].cdev);
                cancel_work_sync(&chip->leds[i].brightness_work);
        }

- In this loop, we call led_classdev_unregister, which invokes
led_brightness_set, and this in turn calls lp5523_set_brightness, which then
calls schedule_work on the uninitialized work queue.  This can panic the kernel.

Can someone look at this and let me know if it's a genuine bug?  I found this
using a tool we've developed and it'd be great to know if it's a false positive.
It looks genuine to me but it'd be great if someone who knows what's going on
could verify it :)  Please let me know if I can provide additional information.

Thanks and regards,
Matt

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux