From patchwork Thu Mar 7 15:26:19 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 2232651 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 051B4DF223 for ; Thu, 7 Mar 2013 15:30:01 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UDciK-0007ZP-Ev; Thu, 07 Mar 2013 15:26:36 +0000 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UDciD-0007Ye-BH for linux-arm-kernel@lists.infradead.org; Thu, 07 Mar 2013 15:26:31 +0000 Received: from e106331-lin.cambridge.arm.com (e106331-lin.cambridge.arm.com [10.1.77.32]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id r27FQJki027909; Thu, 7 Mar 2013 15:26:19 GMT Date: Thu, 7 Mar 2013 15:26:19 +0000 From: Mark Rutland To: "Jon Medhurst (Tixy)" Subject: Re: [BUG] ARM Architected timers appear broken in 3.9-rc1 Message-ID: <20130307152619.GA24366@e106331-lin.cambridge.arm.com> References: <1362654289.3323.18.camel@linaro1.home> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1362654289.3323.18.camel@linaro1.home> Thread-Topic: [BUG] ARM Architected timers appear broken in 3.9-rc1 Accept-Language: en-GB, en-US Content-Language: en-US User-Agent: Mutt/1.5.20 (2009-06-14) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130307_102629_652472_EAF17AFA X-CRM114-Status: GOOD ( 20.17 ) X-Spam-Score: -7.5 (-------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-7.5 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.96.50 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Thu, Mar 07, 2013 at 11:04:49AM +0000, Jon Medhurst (Tixy) wrote: > Hi Mark Hi, > > When booting Versatile Express TC2 I am getting a null pointer > dereference which appears to be related to the recent changes in > architected timer support. > > The interesting part of the call stack is below (the full log is > attached). It shows that whilst entering CPU idle the code is calling > the NULL set_next_event function on the dummy timer setup by > broadcast_timer_setup. As you say, we're calling the NULL set_next_event on the dummy timer, because the dummy is registered as the broadcast device, which makes no sense (as that means it's responsible for broadcasting to itself). As far as I can see, the issue is that the dummy timer has a higher rating (400) than the sp804 (300) that would otherwise be used as the broadcast source, and tick_check_broadcast_device does not reject clocks with CLOCK_EVT_FEAT_DUMMY (which should *never* be used as a broadcast source). Giving the dummy timer a lower rating than the sp804 would prevent this, but it might make more sense to do something like the below and explicitly prevent dummy timers from being registered as broadcast sources (this seems to work for me with your kernel, though I hit an unrelated BUG() later due to bL_platform_power_ops *power_ops not being set). Thomas, what do you think? Thanks, Mark. ---->8---- From 7432019cdfea9b2808e3b04489cd71a89266ca8f Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Thu, 7 Mar 2013 15:09:24 +0000 Subject: [PATCH] clockevents: don't allow dummy broadcast timers Currently tick_check_broadcast_device doesn't reject clock_event_devices with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real hardware if they have a higher rating value. In this situation, the dummy timer is responsible for broadcasting to itself, and the core clockevents code may attempt to call non-existent callbacks for programming the dummy, eventually leading to a panic. This patch makes tick_check_broadcast_device always reject dummy timers, preventing this problem. Signed-off-by: Mark Rutland --- kernel/time/tick-broadcast.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index 2fb8cb8..7f32fe0 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -67,7 +67,8 @@ static void tick_broadcast_start_periodic(struct clock_event_device *bc) */ int tick_check_broadcast_device(struct clock_event_device *dev) { - if ((tick_broadcast_device.evtdev && + if ((dev->features & CLOCK_EVT_FEAT_DUMMY) || + (tick_broadcast_device.evtdev && tick_broadcast_device.evtdev->rating >= dev->rating) || (dev->features & CLOCK_EVT_FEAT_C3STOP)) return 0;