Andrey Savochkin wrote:
>
> On Fri, May 19, 2000 at 10:24:39PM -0700, David S. Miller wrote:
> > Date: Sat, 20 May 2000 15:22:27 +1000
> > From: Andrew Morton <andrewm@xxxxxxxxxx>
> >
> > I have just written a little kernel module which has confirmed that the
> > handler-keeps-running-after-del_timer bug exists in both 2.2.14 and
> > 2.3.99-pre9. Not good. Very not good, IMO.
> >
> > I just noticed this thread, and has del_timer_sync been mentioned yet?
> > That is what should be used to make sure the timer is done in 2.3.x,
> > unless something else prevents it's usage (locking conflict).
>
> del_timer_sync doesn't ensure that the timer has really exited (as opposite
> to just calling timer_exit()).
> We cannot free the code segment where the timer handler resides even
> with del_timer_sync!
yes, there's that. Plus del_timer_sync() is a bit racy anyway. Quoting
myself:
int del_timer_sync(struct timer_list * timer)
{
int ret = 0;
for (;;) {
unsigned long flags;
int running;
spin_lock_irqsave(&timerlist_lock, flags);
** The timer handler could be running now. It can delete the
timer and kfree it, or reuse its memory for something else,
or turn it into a semantically different timer **
ret += detach_timer(timer);
timer->list.next = timer->list.prev = 0;
** uh-oh **
Plus it requires exit_timer(), plus it doesn't exist in 2.2 :(
Regarding this:
( I wanna know why my kernel thread shows up in ps as "insmod
timertest.o" but everyone else's has nifty names like "[kflushd]" )
sprintf(current->comm, "nifty name");
Yes, I did that. My niftyname is "timertest". And indeed, 'killall
timertest' works, but 'ps' still shows it as 'insmod timertest.o'. 2.2
as well as 2.3. Not a very high priority item.
--
-akpm-
|