Re: timer_bh robusteness fix against potential deadlocks

From: arijort@valinux.com
Date: Fri Jan 14 2000 - 17:43:21 EST


Andrea,

Just to be clear...

Are you saying that the entire timer_bh-deadlock patch is bad?
Or simply the hunk that you refer to below, which begins like this:

@@ -1135,17 +1165,20 @@

ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/timer_bh-deadlock-1.gz

I'm assuming it's the whole patch.

ari

On Fri, 14 Jan 2000, Andrea Arcangeli wrote:

> On Wed, 12 Jan 2000, Andrea Arcangeli wrote:
>
> >+ while (timer) {
> > void (*fn)(unsigned long) = timer->function;
> > unsigned long data = timer->data;
> >- detach_timer(timer);
> >- timer->next = timer->prev = NULL;
> >+ struct timer_list * tmp = timer;
> >+ timer = timer->next;
> >+ detach_timer(tmp);
> >+ tmp->next = tmp->prev = NULL;
> > spin_unlock_irq(&timerlist_lock);
>
> If at this point the timer pointed by "timer" gets detached while "fn" is
> running, at the next loop the machine is going to fail. I am sorry.
>
> >Or you can download the patch from here:
> >
> > ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/timer_bh-deadlock-1.gz
> > ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.3/2.3.38/timer_bh-deadlock-1.gz
>
> Please don't use the two timer_bh patches quoted above (neither the -2
> optimized version). Having the timer robust against buggy users is not
> necessary but only desiderable, so actually you don't need it.
> Nevertheless I'll fix the problem soon.
>
> FYI: the delack-timer-3 patch here:
>
> ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/delack-timer-3.gz
>
> seems to fix the wait_on_bh popular deadlock on UP/SMP webservers fine :).
>
> Andrea
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:24 EST