From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: Quick review of -rt RCU-related patches Date: Wed, 05 Oct 2011 00:12:35 +0200 Message-ID: <1317766355.32543.38.camel@twins> References: <20111004174755.GA4762@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: "Paul E. McKenney" , linux-rt-users , LKML To: Thomas Gleixner Return-path: Received: from casper.infradead.org ([85.118.1.10]:44144 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932820Ab1JDWN2 convert rfc822-to-8bit (ORCPT ); Tue, 4 Oct 2011 18:13:28 -0400 In-Reply-To: Sender: linux-rt-users-owner@vger.kernel.org List-ID: On Wed, 2011-10-05 at 00:05 +0200, Thomas Gleixner wrote: > > peter_zijlstra-frob-rcu.patch > > > > Looks OK. Hmmm... Should this one go to mainline? > > Oh, looks equivalent, actually. So why the change? > > Peter ? - if (in_irq() || in_serving_softirq()) { + if (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_OFFSET)) { For !rt its equivalent yes, for rt otoh its not: int in_serving_softirq(void) { int res; preempt_disable(); res = __get_cpu_var(local_softirq_runner) == current; preempt_enable(); return res; } However invoke_softirq() will still add SOFTIRQ_OFFSET so we need to look at that to avoid recursion issues. The changelog describes this. So this change is a direct consequence of -rt frobbing the softirq stuff and thus isn't needed upstream.