lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 27 Oct 2022 23:17:27 -0400 From: Steven Rostedt <rostedt@...dmis.org> To: Hillf Danton <hdanton@...a.com> Cc: linux-kernel@...r.kernel.org, Alan Stern <stern@...land.harvard.edu>, Dan Carpenter <dan.carpenter@...cle.com>, linux-usb@...r.kernel.org Subject: Re: [RFC][PATCH v2 20/31] timers: usb: Use del_timer_shutdown() before freeing timer On Fri, 28 Oct 2022 10:18:15 +0800 Hillf Danton <hdanton@...a.com> wrote: > On 27 Oct 2022 11:05:45 -0400 Steven Rostedt (Google) <rostedt@...dmis.org> > > > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -1261,6 +1261,9 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) > > > > /* Don't do a long sleep inside a workqueue routine */ > > if (type == HUB_INIT2) { > > + /* Timers must be shutdown before they are re-initialized */ > > + if (hub->init_work.work.func) > > + del_timer_shutdown(&hub->init_work.timer); > > This is not needed in the workqueue callback as the timer in question > is not pending. This was added because of the updates to DEBUG_OBJECTS_TIMERS that changed it to require a shutdown to remove the activation of the timer. This is to detect the possibility that a timer may become active just before freeing (there's way too many bugs that show that code logic is not enough). This code in particular is troubling because it re-initializes an already initialized timer with a new function. This causes the debug-objects to trigger an "object activated while initializing" warning. I originally added the "shutdown" to deactivate the object before you re-initialize it. But I have since updated the code to keep track of if it was ever activated, and if so, not to call the init code again, so this may not be required anymore. I'm still trying to work out the kinks as the users of timers have become adapted to the implementation, and may need to add some other helpers to make this work. -- Steve > > > INIT_DELAYED_WORK(&hub->init_work, hub_init_func3); > > queue_delayed_work(system_power_efficient_wq, > > &hub->init_work,
Powered by blists - more mailing lists