aboutsummaryrefslogtreecommitdiff
path: root/kernel/locking/rtmutex-debug.c
diff options
context:
space:
mode:
authorBen Segall <[email protected]>2014-05-19 15:49:45 -0700
committerIngo Molnar <[email protected]>2014-06-05 11:52:00 +0200
commit51f2176d74ace4c3f58579a605ef5a9720befb00 (patch)
tree3c4f8405eacae93ef43707c2d335f8a12212eaeb /kernel/locking/rtmutex-debug.c
parent096aa33863a5e48de52d2ff30e0801b7487944f4 (diff)
sched/fair: Fix unlocked reads of some cfs_b->quota/period
sched_cfs_period_timer() reads cfs_b->period without locks before calling do_sched_cfs_period_timer(), and similarly unthrottle_offline_cfs_rqs() would read cfs_b->period without the right lock. Thus a simultaneous change of bandwidth could cause corruption on any platform where ktime_t or u64 writes/reads are not atomic. Extend cfs_b->lock from do_sched_cfs_period_timer() to include the read of cfs_b->period to solve that issue; unthrottle_offline_cfs_rqs() can just use 1 rather than the exact quota, much like distribute_cfs_runtime() does. There is also an unlocked read of cfs_b->runtime_expires, but a race there would only delay runtime expiry by a tick. Still, the comparison should just be != anyway, which clarifies even that problem. Signed-off-by: Ben Segall <[email protected]> Tested-by: Roman Gushchin <[email protected]> [peterz: Fix compile warn] Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/20140519224945.20303.93530.stgit@sword-of-the-dawn.mtv.corp.google.com Cc: [email protected] Cc: Linus Torvalds <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
Diffstat (limited to 'kernel/locking/rtmutex-debug.c')
0 files changed, 0 insertions, 0 deletions