From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756141Ab1I2Na7 (ORCPT ); Thu, 29 Sep 2011 09:30:59 -0400 Received: from casper.infradead.org ([85.118.1.10]:37137 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753372Ab1I2Na6 convert rfc822-to-8bit (ORCPT ); Thu, 29 Sep 2011 09:30:58 -0400 Subject: Re: [PATCH RFC] lockdep: Update documentation for lock-class leak detection From: Peter Zijlstra To: paulmck@linux.vnet.ibm.com Cc: mingo@redhat.com, linux-kernel@vger.kernel.org Date: Thu, 29 Sep 2011 15:30:19 +0200 In-Reply-To: <20110928181139.GA8217@linux.vnet.ibm.com> References: <20110928181139.GA8217@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.0.3- Message-ID: <1317303019.22581.8.camel@twins> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2011-09-28 at 11:11 -0700, Paul E. McKenney wrote: > There are a number of bugs that can leak lock classes, which will > eventually exhaust the maximum number (currently 8191). However, > the documentation does not tell you how to track down the leakers. > This commit addresses this shortcoming. > > Signed-off-by: Paul E. McKenney > > diff --git a/Documentation/lockdep-design.txt b/Documentation/lockdep-design.txt > index abf768c..24bfd9f 100644 > --- a/Documentation/lockdep-design.txt > +++ b/Documentation/lockdep-design.txt > @@ -221,3 +221,55 @@ when the chain is validated for the first time, is then put into a hash > table, which hash-table can be checked in a lockfree manner. If the > locking chain occurs again later on, the hash table tells us that we > dont have to validate the chain again. > + > +Troubleshooting: > +---------------- > + > +The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes. > +Exceeding this number will trigger the following lockdep warning: > + > + (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)) > + > +By default, MAX_LOCKDEP_KEYS is currently set to 8191, and typical > +desktop systems have less than 1,000 lock classes, so this warning > +normally results from lock-class leakage. Such leakage can result > +from the following: > + > +1. Repeated module loading and unloading while running the validator. > + The issue here is that each load of the module will create a > + new set of lock classes for that module's locks, and module > + unloading cannot remove old classes. Therefore, if that module > + is loaded and unloaded repeatedly, the number of lock classes > + will eventually reach the maximum. > + > +2. Dynamically allocating and freeing structures containing fields > + of type "struct lock_class_key". Again, the fact that old > + lock classes cannot be reused means that repeating allocation/free > + cycles for long enough will cause the number of lock classes to > + eventually reach the maximum. > + This isn't actually true, we check for keys to be in .data or .bss: register_lock_class(): /* * Debug-check: all keys must be persistent! */ if (!static_obj(lock->key)) { debug_locks_off(); printk("INFO: trying to register non-static key.\n"); printk("the code is fine but needs lockdep annotation.\n"); printk("turning off the locking correctness validator.\n"); dump_stack(); return NULL; } But what can happen is that you 'accidentally' create a lot of static locks, eg. struct { spinlock_t lock; struct hlist_head hlist; } my_hash[1 << HASH_BITS]; If you don't initialize the lock members you'll find that each will get a separate lock class based on its static address. This can quickly deplete the class storage. Now really, you shouldn't ever not initialize a lock, but the above has actually happened, although I can't find the commit atm.