On Tue, Feb 05, 2019 at 10:24:47PM +0100, Jacek Anaszewski wrote: > Hi Dmitry, > > On 2/5/19 9:18 AM, Dmitry Torokhov wrote: > > Hi Sven, > > > > On Mon, Feb 04, 2019 at 05:09:52PM -0500, Sven Van Asbroeck wrote: > > > The work which is scheduled by led_classdev->brightness_set() is > > > potentially left pending or running until after the driver module > > > is unloaded. > > > > > > Fix by using resource-controlled version of INIT_WORK(). > > > > I believe this is wrong way of fixing this. The LED classdev objects are > > refcounted, and may live beyond the point where we unwibd devm stack, > > so we are still left with the same use-after-free that we currently > > have. > > Could you please share what LED classdev objects refcounting > do you have on mind?
My mind was in a state of confusion when I wrote the above ;) > > > This is a general issue with LED subsystem as it provides no callback > > for properly tearing down device structures, but I think in this > > particular case we can simply switch from set_brightness() to > > set_brightness_blocking() which will use the work item internal to the > > LED classdev and that one is being shut down properly. > > > > Jacek, does the above sound right? > > Yes, since the introduction of brightness_set_blocking op there is no > need for out-of-led-core workqueues for deferring brightness setting. > And we do flush_work() in led_classdev_unregister(). OK, great, I'll write up a patch for cap11xx and others if I find them. Thanks. -- Dmitry
