[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100326075923.GB2596@dhcp-lab-161.englab.brq.redhat.com>
Date: Fri, 26 Mar 2010 08:59:24 +0100
From: Stanislaw Gruszka <sgruszka@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Americo Wang <xiyou.wangcong@...il.com>,
Balbir Singh <balbir@...ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Ingo Molnar <mingo@...e.hu>,
Roland McGrath <roland@...hat.com>,
Spencer Candland <spencer@...ehost.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC,PATCH 2/2] cputimers/proc:
do_task_stat()->thread_group_times() is racy and O(n) under
->siglock
On Thu, Mar 25, 2010 at 01:12:50PM +0100, Oleg Nesterov wrote:
> > but more importantly I think
> > clock_gettime(CLOCK_PROCESS_CPUTIME_ID) should indeed use ->siglock to
> > ensure it serializes against do_exit() so that either we iterate the
> > thread or get the accumulated runtime from signal_struct but not both
> > (or neither).
>
> Oh. I forgot everything I knew about posix-cpu-timers... But, it seems,
> posix_cpu_clock_get() calls thread_group_cputime() under tasklist and
> thus can't race with exit.
We assure thread_group_cputime() is called with one of: tasklist_lock
or ->siglock to avoid races with __exit_signal. Except oom killer and
elf core-dump code where is no lock, where we assume exit is not called
or we don't care of inaccurate results.
Stanislaw
--
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