Re: [PATCH RFC] time: drop do_sys_times spinlock

From: Rik van Riel
Date: Tue Aug 12 2014 - 15:23:35 EST

Hash: SHA1

On 08/12/2014 03:12 PM, Oleg Nesterov wrote:
> On 08/12, Rik van Riel wrote:
>> Back in 2009, Spencer Candland pointed out there is a race with
>> do_sys_times, where multiple threads calling do_sys_times can
>> sometimes get decreasing results.
>> As a result of that discussion, some of the code in do_sys_times
>> was moved under a spinlock.
>> However, that does not seem to actually make the race go away on
>> larger systems. One obvious remaining race is that after one
>> thread is about to return from do_sys_times, it is preempted by
>> another thread, which also runs do_sys_times, and stores a larger
>> value in the shared variable than what the first thread got.
>> This race is on the kernel/userspace boundary, and not fixable
>> with spinlocks.
> Not sure I understand...
> Afaics, the problem is that a single thread can observe the
> decreasing (say) sum_exec_runtime if it calls do_sys_times() twice
> without the lock.
> This is because it can account the exiting sub-thread twice if it
> races with __exit_signal() which increments sig->sum_sched_runtime,
> but this exiting thread can still be visible to
> thread_group_cputime().
> IOW, it is not actually about decreasing, the problem is that the
> lockless thread_group_cputime() can return the wrong result, and
> the next ys_times() can show the right value.

Hmmm, that is not what the test case does.

The test case simply calls times() once in each thread, and saves
the value in a global variable for the next thread to use.

Does the seq_lock in task_cputime() prevent the problem you are
describing, or does the exit/zombie reaping code need to block the
seq_lock while it moves the stats from the zombie to the group?

- --
All rights reversed
Version: GnuPG v1

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at