lkml.org 
[lkml]   [1999]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] shaper fix for timer SMP races
On Wed, 17 Feb 1999, Regis Duchesne wrote:

>> + start_bh_atomic();
>> del_timer(&shaper->timer);
>> + end_bh_atomic();
>> MOD_DEC_USE_COUNT;
>> return 0;
>> }
>
>Isn't that part of the patch overkill?

No, if the shaper->timer has some chance to be pending (and if it had no
chance to be pending also del_timer() would be an overkill).

>As I understand things, del_timer() must acquire the timerlist_lock
>spinlock to modify the timer list. I guess that all other code

The race is very more fun ;). The race is that you may have the
shaper->timer running on the other CPU while you are deleting it. Yes, the
timerlist is preserved from corruption, but you may remove the vmalloced
module code while the shaper->timer is running.

>(including the code in bottom half handlers) that want to modify the
>timer list do the same.

shaper_kick() now uses mod_timer() (now I can use mod_timer() because I
rewrote the locking scheme) to be sure that the shaper->timer will not
added two times causing the timer_bh() to loop forever.

>So why do we need to use [start|end]_bh_atomic() to guarantee that no
>BH on any CPU will execute while we modify the timer list?

No. The timer list has nothing to do this time with the bh_atomic(). The
bh_atomic will assure us that once we are in line xxxxxxxxxxx:

start_bh_atomic();
del_timer(&shaper->timer);
end_bh_atomic();
xxxxxxxxxxxx

we won't have the shaper->timer pending or _running_ anymore.

Andrea Arcangeli


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.044 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site