Re: [PATCH v2] leds: lp5860: Return an error for an out-of-range 'reg' property
Mert Seftali <[email protected]>
| Newsgroups | org.kernel.vger.linux-leds,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAA3Nooqdrt6pMMNVdq8gh5RZLjAkrRzboF7n-_SZ5oL91KHJDw@mail.gmail.com> |
On Thu, 2 Jul 2026, Lee Jones wrote: > This is also a pre-existing issue, but I noticed a potential > use-after-destroy involving the same mutex in the removal path: > [...] > Does this sequence result in lp5860_chip_enable() locking a mutex that > was just destroyed by lp5860_remove()? Hi Lee, following up on the use-after-destroy: i looked into it properly and the swap i mentioned isn't enough on its own. Even with device_remove() before mutex_destroy(), the mutex is still destroyed inside .remove(). The LED classdevs are devm-registered, so they get torn down afterwards and led_classdev_unregister() sets brightness to LED_OFF which runs the blocking setter under guard(mutex)(&chip->lock). So that teardown locks the mutex after .remove() has already destroyed it. I reproduced the ordering under DEBUG_MUTEXES with a small devres + mutex test that mirrors that teardown (i don't have the part): with the swap, device_remove() comes out fine but the mirrored teardown still trips DEBUG_LOCKS_WARN_ON(lock->magic != lock), and deferring the destroy clears it. So i'd switch the lock to devm_mutex_init() and drop the manual mutex_destroy() from .remove(). devres then destroys it in LIFO order after the LED classdevs are unregistered, so nothing locks it once it is gone. That covers the case you flagged and this teardown path too. Thanks, Mert