[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100329181359.GD16356@redhat.com>
Date: Mon, 29 Mar 2010 20:13:59 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Balbir Singh <balbir@...ux.vnet.ibm.com>,
Americo Wang <xiyou.wangcong@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
Roland McGrath <roland@...hat.com>,
Spencer Candland <spencer@...ehost.com>,
Stanislaw Gruszka <sgruszka@...hat.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH -mm 3/4] cputimers: thread_group_times: make it rcu-safe
thread_group_times() relies on ->siglock hold by the caller when it
updates sig->prev_Xtime members. Change the code to take cputimer.lock
around the assignment.
This makes it rcu-safe and fixes the theoretical race. wait_task_zombie()
calls it lockless and thus can race with do_task_stat().
Note: we are taking cputimer.lock under ->siglock but this dependency
is not new, thread_group_cputimer() already does this.
Signed-off-by: Oleg Nesterov <oleg@...hat.com>
---
kernel/sched.c | 3 +++
1 file changed, 3 insertions(+)
--- 34-rc1/kernel/sched.c~cpuacct_3_thread_group_times_dont_rely_on_siglock 2010-03-29 19:44:25.000000000 +0200
+++ 34-rc1/kernel/sched.c 2010-03-29 19:46:21.000000000 +0200
@@ -3449,6 +3449,7 @@ void thread_group_times(struct task_stru
struct signal_struct *sig = p->signal;
struct task_cputime cputime;
cputime_t rtime, utime, total;
+ unsigned long flags;
thread_group_cputime(p, &cputime);
@@ -3464,9 +3465,11 @@ void thread_group_times(struct task_stru
} else
utime = rtime;
+ spin_lock_irqsave(&sig->cputimer.lock, flags);
sig->prev_utime = max(sig->prev_utime, utime);
sig->prev_stime = max(sig->prev_stime,
cputime_sub(rtime, sig->prev_utime));
+ spin_unlock_irqrestore(&sig->cputimer.lock, flags);
*ut = sig->prev_utime;
*st = sig->prev_stime;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists