diff options
author | Roland McGrath <roland@redhat.com> | 2005-10-19 22:21:23 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2005-10-19 23:02:01 -0700 |
commit | e03d13e985d48ac4885382c9e3b1510c78bd047f (patch) | |
tree | 04a124c1759f4b16e21fd04031ee9677fab58021 /mm | |
parent | 3359b54c8c07338f3a863d1109b42eebccdcf379 (diff) | |
download | linux-3.10-e03d13e985d48ac4885382c9e3b1510c78bd047f.tar.gz linux-3.10-e03d13e985d48ac4885382c9e3b1510c78bd047f.tar.bz2 linux-3.10-e03d13e985d48ac4885382c9e3b1510c78bd047f.zip |
[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
exit_itimers.
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: Roland McGrath <roland@redhat.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions