]> git.karo-electronics.de Git - karo-tx-linux.git/commit
Fix timer race in dst GC code
authorDmitry Mishin <dim@openvz.org>
Fri, 17 Nov 2006 16:53:07 +0000 (17:53 +0100)
committerAdrian Bunk <bunk@stusta.de>
Fri, 17 Nov 2006 16:53:07 +0000 (17:53 +0100)
commit9e9c71470300baacb977ef0f332038691f8dc46a
tree0b9600289a97a180f57ee2cc3305e70509014607
parent770af3b42ad36c622586eee13db3799837567102
Fix timer race in dst GC code

Replace add_timer() by mod_timer() in dst_run_gc
in order to avoid BUG message.

   CPU1                            CPU2
dst_run_gc()  entered           dst_run_gc() entered
spin_lock(&dst_lock)                   .....
del_timer(&dst_gc_timer)         fail to get lock
   ....                         mod_timer() <--- puts
                                             timer back
                                             to the list
add_timer(&dst_gc_timer) <--- BUG because timer is in list already.

Found during OpenVZ internal testing.

At first we thought that it is OpenVZ specific as we
added dst_run_gc(0) call in dst_dev_event(),
but as Alexey pointed to me it is possible to trigger
this condition in mainstream kernel.

F.e. timer has fired on CPU2, but the handler was preeempted
by an irq before dst_lock is tried.
Meanwhile, someone on CPU1 adds an entry to gc list and
starts the timer.
If CPU2 was preempted long enough, this timer can expire
simultaneously with resuming timer handler on CPU1, arriving
exactly to the situation described.

Signed-off-by: Dmitry Mishin <dim@openvz.org>
Signed-off-by: Kirill Korotaev <dev@openvz.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
net/core/dst.c