Hello Pavel, On Mon, May 23, 2022 at 09:35:10AM +0200, Uwe Kleine-König wrote: > On Fri, May 13, 2022 at 04:36:57PM +0200, Uwe Kleine-König wrote: > > On Fri, May 13, 2022 at 04:02:55PM +0200, Pavel Machek wrote: > > > > The mutex might still be in use until the devm cleanup callback > > > > devm_led_classdev_flash_release() is called. This only happens some time > > > > after lm3601x_remove() completed. > > > > > > I'm sure lots of "use after free" can be fixed by simply removing the > > > resource freeing... > > > > I agree in general. Mutexes are a bit special here and often are not > > destroyed. mutex_destroy() is a no-op usually and with debugging enabled > > only does > > > > lock->magic = NULL; > > > > which catches use-after-destroy. So IMHO just dropping the mutex_destroy > > is fine. > > > > > but lets fix this properly. > > > > I don't understand that part. Does that mean you pick up my patch, or > > that you create a better fix? > > You didn't pick up this patch up to now and also I didn't see a better > fix. > > So I wonder what is your plan/vision here. The obvious alternatives are > to call mutex_destroy only in a devm callback that is registered before > calling lm3601x_register_leds(), or don't used devm to register the LED. Any news on this? If you're waiting for a better fix from me, please tell my your expectations. A devm variant of mutex_init would be an option, but that feels like a very big hammer for a small nail. I still consider my patch fine. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
