Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932808AbbDNXKp (ORCPT ); Tue, 14 Apr 2015 19:10:45 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:20718 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932544AbbDNXKe (ORCPT ); Tue, 14 Apr 2015 19:10:34 -0400 From: Jason Low To: Linus Torvalds , Peter Zijlstra , Ingo Molnar , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, "Paul E. McKenney" , Andrew Morton , Oleg Nesterov , Mike Galbraith , Frederic Weisbecker , Mel Gorman , Steven Rostedt , Preeti U Murthy , hideaki.kimura@hp.com, Aswin Chandramouleeswaran , Scott J Norton , Jason Low Subject: [PATCH 3/3] sched, timer: Use cmpxchg to do updates in update_gt_cputime() Date: Tue, 14 Apr 2015 16:09:46 -0700 Message-Id: <1429052986-9420-4-git-send-email-jason.low2@hp.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1429052986-9420-1-git-send-email-jason.low2@hp.com> References: <1429052986-9420-1-git-send-email-jason.low2@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3145 Lines: 76 Note: The chance that the race which this patch addresses seems very unlikely to occur, especially after the change in patch 2 which sets the running field after calling this update_gt_cputimer(). However, I am including this patch if we want to be completely safe from concurrent updates. ----------------------------------------------------------------------------- Since we're now updating thread group cputimer values without a lock, there is now a potential race that can occur in update_gt_cputime() where the cputimers are concurrently being updated in account_group_*_time(). This can occur when the ->running field transitions from 1 -> 0 -> 1. If the cputimer->running field is set while thread 1 runs run_posix_cpu_timers(), but another thread, thread 2, turns off cputimer->running before thread 1 enters thread_group_cputimer(), and another thread, thread 3, enables it after thread 1 checks !cputimer->running in thread_group_cputimer(), then there is a possibility that update_gt_cputime() is updating the cputimers while the cputimer is running. This patch uses cmpxchg and retry logic to ensure that update_gt_cputime() is making its updates atomically. Signed-off-by: Jason Low --- kernel/time/posix-cpu-timers.c | 26 ++++++++++++++++++-------- 1 files changed, 18 insertions(+), 8 deletions(-) diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c index 7e96082..130d717 100644 --- a/kernel/time/posix-cpu-timers.c +++ b/kernel/time/posix-cpu-timers.c @@ -196,16 +196,26 @@ static int cpu_clock_sample(const clockid_t which_clock, struct task_struct *p, return 0; } -static void update_gt_cputime(struct thread_group_cputimer *cputimer, struct task_cputime *sum) +static inline void __update_gt_cputime(atomic64_t *cputime, u64 sum_cputime) { - if (sum->utime > atomic64_read(&cputimer->utime)) - atomic64_set(&cputimer->utime, sum->utime); - - if (sum->stime > atomic64_read(&cputimer->stime)) - atomic64_set(&cputimer->stime, sum->stime); + u64 curr_cputime; + /* + * Set cputime to sum_cputime if sum_cputime > cputime. Use cmpxchg + * to avoid race conditions with concurrent updates to cputime. + */ +retry: + curr_cputime = atomic64_read(cputime); + if (sum_cputime > curr_cputime) { + if (atomic64_cmpxchg(cputime, curr_cputime, sum_cputime) != curr_cputime) + goto retry; + } +} - if (sum->sum_exec_runtime > atomic64_read(&cputimer->sum_exec_runtime)) - atomic64_set(&cputimer->sum_exec_runtime, sum->sum_exec_runtime); +static void update_gt_cputime(struct thread_group_cputimer *cputimer, struct task_cputime *sum) +{ + __update_gt_cputime(&cputimer->utime, sum->utime); + __update_gt_cputime(&cputimer->stime, sum->stime); + __update_gt_cputime(&cputimer->sum_exec_runtime, sum->sum_exec_runtime); } /* Sample thread_group_cputimer values in "cputimer", copy results to "times" */ -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/