sched, time: Atomically increment stime & utime
authorRik van Riel <riel@redhat.com>
Fri, 15 Aug 2014 20:05:38 +0000 (16:05 -0400)
committerIngo Molnar <mingo@kernel.org>
Mon, 8 Sep 2014 06:17:02 +0000 (08:17 +0200)
commiteb1b4af0a64ac7bb0ee36f579c1c7cefcbc3ac2c
treeb8a48561d5a51a5b5249d987f1ecfa97a0a44fbc
parente78c3496790ee8a36522a838b59b388e8a709e65
sched, time: Atomically increment stime & utime

The functions task_cputime_adjusted and thread_group_cputime_adjusted()
can be called locklessly, as well as concurrently on many different CPUs.

This can occasionally lead to the utime and stime reported by times(), and
other syscalls like it, going backward. The cause for this appears to be
multiple threads racing in cputime_adjust(), both with values for utime or
stime that is larger than the original, but each with a different value.

Sometimes the larger value gets saved first, only to be immediately
overwritten with a smaller value by another thread.

Using atomic exchange prevents that problem, and ensures time
progresses monotonically.

Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: umgwanakikbuti@gmail.com
Cc: fweisbec@gmail.com
Cc: akpm@linux-foundation.org
Cc: srao@redhat.com
Cc: lwoodman@redhat.com
Cc: atheurer@redhat.com
Cc: oleg@redhat.com
Link: http://lkml.kernel.org/r/1408133138-22048-4-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
kernel/sched/cputime.c