From patchwork Mon Feb 10 21:16:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 24429 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-yk0-f199.google.com (mail-yk0-f199.google.com [209.85.160.199]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 787DD20143 for ; Mon, 10 Feb 2014 21:16:52 +0000 (UTC) Received: by mail-yk0-f199.google.com with SMTP id 10sf18472063ykt.2 for ; Mon, 10 Feb 2014 13:16:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe; bh=xt0TjodvxjwKCE1gHE8Nt46APpaD8mkjpgMk8uoyxXw=; b=V/V3QdJpXH9gi4EWaeUrYRvG5wtz0yylwYpNduh0hhVt6wI1jcnki4MHS7lR7ghBf6 NYWO+tw22LjkpEvLfBuIXC6QDjiTPxzBEMl1kKkVCE+u1+TB8f6hnJK+ym5YZ1wMC2Mw o09ZfcLIJQSAZtkRQcn12OV7gHBu66Moe2F8Hm5ok07dWSfCQCiMFuCU0vjmlOTc+Wbo g22kJl+AYGRov29B9uvUR7hWUCb5aBedRhhelS/N+n0Gxp3/ftQJxnk+xSjtKwIkwHde Lrx+q3Lx53fuI87CVN8jNpq3KeGGdg+mvfY79lsM/O8ShSTUVdDu8jw0YIUr5hcup95n jWhA== X-Gm-Message-State: ALoCoQnfmJ+EHZ1kmTFVjgD5USG1yqV7bUkFDcCEPmWKs6XwIh5mq+OccvnOfEnohzffCxrzwZPr X-Received: by 10.224.20.133 with SMTP id f5mr12945216qab.8.1392067011508; Mon, 10 Feb 2014 13:16:51 -0800 (PST) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.49.113 with SMTP id p104ls2161745qga.41.gmail; Mon, 10 Feb 2014 13:16:51 -0800 (PST) X-Received: by 10.52.65.171 with SMTP id y11mr58402vds.52.1392067011390; Mon, 10 Feb 2014 13:16:51 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx.google.com with ESMTPS id tt2si5156254vdc.9.2014.02.10.13.16.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 13:16:51 -0800 (PST) Received-SPF: neutral (google.com: 209.85.212.45 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.212.45; Received: by mail-vb0-f45.google.com with SMTP id m10so5180406vbh.18 for ; Mon, 10 Feb 2014 13:16:51 -0800 (PST) X-Received: by 10.53.13.44 with SMTP id ev12mr21390173vdd.17.1392067011263; Mon, 10 Feb 2014 13:16:51 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.220.174.196 with SMTP id u4csp198270vcz; Mon, 10 Feb 2014 13:16:41 -0800 (PST) X-Received: by 10.67.5.131 with SMTP id cm3mr27981302pad.92.1392067000723; Mon, 10 Feb 2014 13:16:40 -0800 (PST) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by mx.google.com with ESMTPS id m8si16638380pbq.209.2014.02.10.13.16.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 13:16:40 -0800 (PST) Received-SPF: neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) client-ip=209.85.220.41; Received: by mail-pa0-f41.google.com with SMTP id fa1so6753770pad.28 for ; Mon, 10 Feb 2014 13:16:40 -0800 (PST) X-Received: by 10.66.149.231 with SMTP id ud7mr28410418pab.8.1392067000276; Mon, 10 Feb 2014 13:16:40 -0800 (PST) Received: from localhost.localdomain (c-67-170-153-23.hsd1.or.comcast.net. [67.170.153.23]) by mx.google.com with ESMTPSA id bc4sm45674905pbb.2.2014.02.10.13.16.38 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 13:16:38 -0800 (PST) From: John Stultz To: stable Cc: John Stultz , Thomas Gleixner , Prarit Bhargava , Richard Cochran , Ingo Molnar , Sasha Levin Subject: [PATCH 2/3] 3.4.y: timekeeping: Avoid possible deadlock from clock_was_set_delayed Date: Mon, 10 Feb 2014 13:16:28 -0800 Message-Id: <1392066989-5113-3-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: <1392066989-5113-1-git-send-email-john.stultz@linaro.org> References: <1392066989-5113-1-git-send-email-john.stultz@linaro.org> X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: john.stultz@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.212.45 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , This is a 3.4-stable backport of 6fdda9a9c5db367130cf32df5d6618d08b89f46a As part of normal operaions, the hrtimer subsystem frequently calls into the timekeeping code, creating a locking order of hrtimer locks -> timekeeping locks clock_was_set_delayed() was suppoed to allow us to avoid deadlocks between the timekeeping the hrtimer subsystem, so that we could notify the hrtimer subsytem the time had changed while holding the timekeeping locks. This was done by scheduling delayed work that would run later once we were out of the timekeeing code. But unfortunately the lock chains are complex enoguh that in scheduling delayed work, we end up eventually trying to grab an hrtimer lock. Sasha Levin noticed this in testing when the new seqlock lockdep enablement triggered the following (somewhat abrieviated) message: [ 251.100221] ====================================================== [ 251.100221] [ INFO: possible circular locking dependency detected ] [ 251.100221] 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053 Not tainted [ 251.101967] ------------------------------------------------------- [ 251.101967] kworker/10:1/4506 is trying to acquire lock: [ 251.101967] (timekeeper_seq){----..}, at: [] retrigger_next_event+0x56/0x70 [ 251.101967] [ 251.101967] but task is already holding lock: [ 251.101967] (hrtimer_bases.lock#11){-.-...}, at: [] retrigger_next_event+0x3c/0x70 [ 251.101967] [ 251.101967] which lock already depends on the new lock. [ 251.101967] [ 251.101967] [ 251.101967] the existing dependency chain (in reverse order) is: [ 251.101967] -> #5 (hrtimer_bases.lock#11){-.-...}: [snipped] -> #4 (&rt_b->rt_runtime_lock){-.-...}: [snipped] -> #3 (&rq->lock){-.-.-.}: [snipped] -> #2 (&p->pi_lock){-.-.-.}: [snipped] -> #1 (&(&pool->lock)->rlock){-.-...}: [ 251.101967] [] validate_chain+0x6c3/0x7b0 [ 251.101967] [] __lock_acquire+0x4ad/0x580 [ 251.101967] [] lock_acquire+0x182/0x1d0 [ 251.101967] [] _raw_spin_lock+0x40/0x80 [ 251.101967] [] __queue_work+0x1a9/0x3f0 [ 251.101967] [] queue_work_on+0x98/0x120 [ 251.101967] [] clock_was_set_delayed+0x21/0x30 [ 251.101967] [] do_adjtimex+0x111/0x160 [ 251.101967] [] compat_sys_adjtimex+0x41/0x70 [ 251.101967] [] ia32_sysret+0x0/0x5 [ 251.101967] -> #0 (timekeeper_seq){----..}: [snipped] [ 251.101967] other info that might help us debug this: [ 251.101967] [ 251.101967] Chain exists of: timekeeper_seq --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock#11 [ 251.101967] Possible unsafe locking scenario: [ 251.101967] [ 251.101967] CPU0 CPU1 [ 251.101967] ---- ---- [ 251.101967] lock(hrtimer_bases.lock#11); [ 251.101967] lock(&rt_b->rt_runtime_lock); [ 251.101967] lock(hrtimer_bases.lock#11); [ 251.101967] lock(timekeeper_seq); [ 251.101967] [ 251.101967] *** DEADLOCK *** [ 251.101967] [ 251.101967] 3 locks held by kworker/10:1/4506: [ 251.101967] #0: (events){.+.+.+}, at: [] process_one_work+0x200/0x530 [ 251.101967] #1: (hrtimer_work){+.+...}, at: [] process_one_work+0x200/0x530 [ 251.101967] #2: (hrtimer_bases.lock#11){-.-...}, at: [] retrigger_next_event+0x3c/0x70 [ 251.101967] [ 251.101967] stack backtrace: [ 251.101967] CPU: 10 PID: 4506 Comm: kworker/10:1 Not tainted 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053 [ 251.101967] Workqueue: events clock_was_set_work So the best solution is to avoid calling clock_was_set_delayed() while holding the timekeeping lock, and instead using a flag variable to decide if we should call clock_was_set() once we've released the locks. This works for the case here, where the do_adjtimex() was the deadlock trigger point. Unfortuantely, in update_wall_time() we still hold the jiffies lock, which would deadlock with the ipi triggered by clock_was_set(), preventing us from calling it even after we drop the timekeeping lock. So instead call clock_was_set_delayed() at that point. Cc: Thomas Gleixner Cc: Prarit Bhargava Cc: Richard Cochran Cc: Ingo Molnar Cc: Sasha Levin Cc: stable #3.10+ Reported-by: Sasha Levin Tested-by: Sasha Levin Signed-off-by: John Stultz --- kernel/time/timekeeping.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index eff0b1e..59b8966 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -988,7 +988,8 @@ static void timekeeping_adjust(s64 offset) * * Returns the unconsumed cycles. */ -static cycle_t logarithmic_accumulation(cycle_t offset, int shift) +static cycle_t logarithmic_accumulation(cycle_t offset, int shift, + unsigned int *clock_set) { u64 nsecps = (u64)NSEC_PER_SEC << timekeeper.shift; u64 raw_nsecs; @@ -1010,7 +1011,7 @@ static cycle_t logarithmic_accumulation(cycle_t offset, int shift) timekeeper.xtime.tv_sec += leap; timekeeper.wall_to_monotonic.tv_sec -= leap; if (leap) - clock_was_set_delayed(); + *clock_set = 1; } /* Accumulate raw time */ @@ -1042,6 +1043,7 @@ static void update_wall_time(void) struct clocksource *clock; cycle_t offset; int shift = 0, maxshift; + unsigned int clock_set = 0; unsigned long flags; write_seqlock_irqsave(&timekeeper.lock, flags); @@ -1077,7 +1079,7 @@ static void update_wall_time(void) maxshift = (64 - (ilog2(ntp_tick_length())+1)) - 1; shift = min(shift, maxshift); while (offset >= timekeeper.cycle_interval) { - offset = logarithmic_accumulation(offset, shift); + offset = logarithmic_accumulation(offset, shift, &clock_set); if(offset < timekeeper.cycle_interval<