Commit e03d13e9 authored by Roland McGrath's avatar Roland McGrath Committed by Linus Torvalds
Browse files

[PATCH] Fix cpu timers exit deadlock and races

Oleg Nesterov reported an SMP deadlock.  If there is a running timer
tracking a different process's CPU time clock when the process owning
the timer exits, we deadlock on tasklist_lock in posix_cpu_timer_del via

That code was using tasklist_lock to check for a race with __exit_signal
being called on the timer-target task and clearing its ->signal.
However, there is actually no such race.  __exit_signal will have called
posix_cpu_timers_exit and posix_cpu_timers_exit_group before it does
that.  Those will clear those k_itimer's association with the dying
task, so posix_cpu_timer_del will return early and never reach the code
in question.

In addition, posix_cpu_timer_del called from exit_itimers during execve
or directly from timer_delete in the process owning the timer can race
with an exiting timer-target task to cause a double put on timer-target
task struct.  Make sure we always access cpu_timers lists with sighand
lock held.
Signed-off-by: default avatarRoland McGrath <>
Signed-off-by: default avatarChris Wright <>
Signed-off-by: default avatarLinus Torvalds <>
parent 3359b54c
......@@ -387,25 +387,19 @@ int posix_cpu_timer_del(struct k_itimer *timer)
if (unlikely(p == NULL))
return 0;
if (!list_empty(&timer->it.cpu.entry)) {
if (unlikely(p->signal == NULL)) {
* We raced with the reaping of the task.
* The deletion should have cleared us off the list.
} else {
* Take us off the task's timer list.
* Take us off the task's timer list. We don't need to
* take tasklist_lock and check for the task being reaped.
* If it was reaped, it already called posix_cpu_timers_exit
* and posix_cpu_timers_exit_group to clear all the timers
* that pointed to it.
return 0;
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment