Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758177Ab1FGTXK (ORCPT ); Tue, 7 Jun 2011 15:23:10 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:47345 "EHLO e8.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754394Ab1FGTXI (ORCPT ); Tue, 7 Jun 2011 15:23:08 -0400 Date: Tue, 7 Jun 2011 12:22:25 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Milton Miller , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , LKML Subject: Re: [1/4] rcu: Detect uses of rcu read side in extended quiescent states Message-ID: <20110607192225.GG2286@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1307329858-14999-3-git-send-email-fweisbec@gmail.com> <20110606181021.GL3066@linux.vnet.ibm.com> <20110607001905.GE17026@somewhere.redhat.com> <20110607004250.GZ3066@linux.vnet.ibm.com> <20110607013630.GF17026@somewhere.redhat.com> <20110607044005.GB2292@linux.vnet.ibm.com> <20110607125809.GA23214@somewhere> <20110607183414.GF2286@linux.vnet.ibm.com> <20110607184857.GC23214@somewhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110607184857.GC23214@somewhere> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2918 Lines: 61 On Tue, Jun 07, 2011 at 08:49:01PM +0200, Frederic Weisbecker wrote: > On Tue, Jun 07, 2011 at 11:34:14AM -0700, Paul E. McKenney wrote: > > On Tue, Jun 07, 2011 at 02:58:13PM +0200, Frederic Weisbecker wrote: > > > On Mon, Jun 06, 2011 at 09:40:05PM -0700, Paul E. McKenney wrote:> > > > > The bit I am missing is how to distinguish between spinlocks (where > > > > sleeping is illegal) and mutexes (where sleeping is perfectly fine). > > > > We could teach lockdep the difference, I suppose, but it is not clear > > > > to me that it is worth it. > > > > > > Ah, in fact it doesn't pass through any lockdep check. > > > > > > It's only a function called might_sleep() that is placed in functions > > > that can sleep. And inside might_sleep() it checks whether it is in a preemptible > > > area. So it's actually locking-agnostic, it only relies on the preempt_count > > > and some more for the preempt rcu cases. > > > > > > I think it is called CONFIG_DEBUG_SPINLOCK_SLEEP because it was first used > > > for spinlock debugging purposes. But then it has a broader use now: sleep > > > inside preemptible section, sleep inside interrupts, sleep inside rcu. > > > > But the __might_sleep() function can only differentiate between > > spinlocks and sleeplocks if CONFIG_PREEMPT=y. > > It doesn't differentiate between locks but checks on the lowest level > by looking at the preempt count. But yeah it only works if CONFIG_PREEMPT, > which is why I proposed to inc/dec the preempt count also when we have > that DEBUG_SPINLOCK_SLEEP. Ah, I missed your proposal to inc/dec preempt_count for PREEMPT=n and DEBUG_SPINLOCK_SLEEP=y. > > > It certainly deserves a rename, like CONFIG_DEBUG_ILLEGAL_SLEEP. > > > > Hmmm... It already checks for sleeping in the middle of a > > preempt_disable() as well as in a spinlock critical section. > > So the need for a rename is independent of any RCU checking. > > Sure, rcu just adds itself to the pile of users of might_sleep(), thus > it would be a nice cleanup to rename the option to something more > generic. But that rename is not necessary to improve RCU checking. Agreed! > > > > In contrast, with RCU, this is straightforward -- check for rcu_sched > > > > and rcu_bh, but not SRCU. > > > > Actually it makes sense to keep the checks in rcu_note_context_switch(), > > as there are places that call schedule() directly without a might_sleep(). > > Perhaps having checks in both places is the correct approach? > > In this case it makes more sense to add your checks in schedule_debug(), > so that we don't wait for a context switch to detect the bug. You might well be right -- looking at it. Thanx, Paul -- 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/