From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754648AbbCBOyL (ORCPT ); Mon, 2 Mar 2015 09:54:11 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:39728 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753759AbbCBOyF (ORCPT ); Mon, 2 Mar 2015 09:54:05 -0500 Date: Mon, 2 Mar 2015 15:53:54 +0100 From: Peter Zijlstra To: Preeti U Murthy Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH] tick/broadcast-hrtimer : Fix suspicious RCU usage in idle loop Message-ID: <20150302145354.GM21418@twins.programming.kicks-ass.net> References: <20150226032202.20019.91636.stgit@preeti.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150226032202.20019.91636.stgit@preeti.in.ibm.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 26, 2015 at 08:52:02AM +0530, Preeti U Murthy wrote: > The hrtimer mode of broadcast queues hrtimers in the idle entry > path so as to wakeup cpus in deep idle states. Callgraph please... > hrtimer_{start/cancel} > functions call into tracing which uses RCU. But it is not legal to call > into RCU in cpuidle because it is one of the quiescent states. Hence > protect this region with RCU_NONIDLE which informs RCU that the cpu > is momentarily non-idle. It it not clear to me that every user of bc_set_next() is from IDLE. >>From what I can tell it ends up being clockevents_program_event() and that is called quite a lot. Why is bc_set_next() a good function to annotate?