Messages in this thread | | | Date | Thu, 7 Apr 2022 14:58:02 -0700 | From | Guenter Roeck <> | Subject | Re: [RFC][PATCH] timers: Add del_time_free() to be called before freeing timers |
| |
Hi Steven,
On Thu, Apr 07, 2022 at 04:17:45PM -0400, Steven Rostedt wrote: > [ > This is an RFC patch. As we hit a few bugs were del_timer() is called > instead of del_timer_sync() before the timer is freed, and there could > be bugs where even del_timer_sync() is used, but the timer gets rearmed, > I decided to introduce a "del_timer_free()" function that can be used > instead. This will at least educate developers on what to call before they > free a structure that holds a timer. > > In this RFC, I modified hci_qca.c as a use case, even though that change > needs some work, because the workqueue could still rearm it (I'm looking > to see if I can trigger the warning). > > If this approach is acceptable, then I will remove the hci_qca.c portion > from this patch, and create a series of patches to use the > del_timer_free() in all the locations in the kernel that remove the timer > before freeing. > ] > > From: "Steven Rostedt (Google)" <rostedt@goodmis.org> > > We are hitting a common bug were a timer is being triggered after it is > freed. This causes a corruption in the timer link list and crashes the > kernel. Unfortunately it is not easy to know what timer it was that was > freed. Looking at the code, it appears that there are several cases that > del_timer() is used when del_timer_sync() should have been. > > Add a del_timer_free() that not only does a del_timer_sync() but will mark
This limits the use case to situations where del_timer_sync() can actually be called. There is, however, code where this is not possible. Specifically, it doesn't work if the code triggered with the timer uses a lock, and del_timer() is also called under that same lock. An example for that is the code in sound/synth/emux/emux.c. How do you suggest to handle that situation ?
Thanks, Guenter
| |