The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Greg KH <gregkh@suse.de>, Thomas Gleixner <tglx@linutronix.de>,
	Cong Wang <amwang@redhat.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>, Miles Lane <miles.lane@gmail.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Patch 0/2] sysfs: fix s_active lockdep warning
Date: Thu, 04 Feb 2010 17:41:53 +0100	[thread overview]
Message-ID: <1265301713.22001.128.camel@laptop> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1002041027070.2470-100000@iolanthe.rowland.org>

On Thu, 2010-02-04 at 11:35 -0500, Alan Stern wrote:
> Greg:
> 
> You have accepted Thomas's patch "drivers/base: Convert dev->sem to
> mutex".  It generates lockdep violations galore during device probing
> and removal!  Luckily lockdep is smart enough only to print the first
> occurrence.  Here's what I get early on during bootup:

<snip lockdep splat>

> On Thu, 4 Feb 2010, Peter Zijlstra wrote:
> 
> > The device tree had the problem that we could basically hold a device
> > lock and an unspecified number of parent locks (iirc this was due to
> > device probing, where we hold the bus lock while probing/adding child
> > device, recursively). 
> > 
> > If we place each dev->lock into the same class (which would naively
> > happen), then this would lead to recursive lock warnings. The proposed
> > solution for this is to create MAX_LOCK_DEPTH classes and assign them to
> > the dev->lock depending on the depth in the device tree (Alan said that
> > MAX_LOCK_DEPTH is sufficient for all practical cases).
> > 
> > static struct lock_class_key dev_tree_classes[MAX_LOCK_DEPTH];
> > 
> > device_add() or thereabouts would have something like:
> > 
> > #ifdef CONFIG_PROVE_LOCKING
> > 	BUG_ON(dev->depth >= MAX_LOCK_DEPTH);
> > 	lockdep_set_class(dev->lock, &dev_tree_classes[dev->depth]);
> > #endif
> 
> Unfortunately this doesn't really work.  Here is a patch implementing
> the scheme:
> 
> Index: usb-2.6/drivers/base/core.c
> ===================================================================
> --- usb-2.6.orig/drivers/base/core.c
> +++ usb-2.6/drivers/base/core.c
> @@ -22,6 +22,7 @@
>  #include <linux/kallsyms.h>
>  #include <linux/mutex.h>
>  #include <linux/async.h>
> +#include <linux/sched.h>
>  
>  #include "base.h"
>  #include "power/power.h"
> @@ -671,6 +672,26 @@ static void setup_parent(struct device *
>  		dev->kobj.parent = kobj;
>  }
>  
> +#ifdef CONFIG_PROVE_LOCKING
> +static struct lock_class_key dev_tree_classes[MAX_LOCK_DEPTH];
> +
> +static void setup_mutex_depth(struct device *dev, struct device *parent)
> +{
> +	int depth = 0;
> +
> +	/* Dynamically determine the device's depth in the device tree */
> +	while (parent) {
> +		++depth;
> +		parent = parent->parent;
> +	}
> +	BUG_ON(depth > MAX_LOCK_DEPTH);
> +	lockdep_set_class(&dev->mutex, &dev_tree_classes[depth]);
> +}
> +#else
> +static inline void setup_mutex_depth(struct device *dev,
> +		struct device *parent) {}
> +#endif
> +
>  static int device_add_class_symlinks(struct device *dev)
>  {
>  	int error;
> @@ -912,6 +933,7 @@ int device_add(struct device *dev)
>  
>  	parent = get_device(dev->parent);
>  	setup_parent(dev, parent);
> +	setup_mutex_depth(dev, parent);
>  
>  	/* use parent numa_node */
>  	if (parent)
> 
> 
> This doesn't address the fact that we really have multiple device trees
> (for example, class devices are handled separately from normal
> devices).  With the above patch installed, I still get lockdep
> violations farther on during boot:

<snip lockdep splat>

Hmm, so you have multiple interacting trees? I had understood you only
had a single device tree. So how many trees are there, is that fixed?
Does the device know what tree it is going to end up in?

If yes, then you can extend the setup_mutex_depth() function to pick a
different class stack for each tree.


  reply	other threads:[~2010-02-04 16:44 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-29  7:01 [Patch 0/2] sysfs: fix s_active lockdep warning Amerigo Wang
2010-01-29  7:02 ` [Patch 1/2] sysfs: add support for lockdep subclasses to s_active Amerigo Wang
2010-01-29  7:02 ` [PATCH 2/2] sysfs: fix the incomplete part of subclass support for s_active Amerigo Wang
2010-01-29  7:21 ` [Patch 0/2] sysfs: fix s_active lockdep warning Eric W. Biederman
2010-01-29  8:38   ` Cong Wang
2010-01-29 13:44     ` Eric W. Biederman
2010-01-29 14:22       ` Greg KH
2010-01-29 17:57         ` Peter Zijlstra
2010-01-29 18:10           ` Greg KH
2010-01-29 18:14             ` Peter Zijlstra
2010-01-29 18:21               ` Greg KH
2010-01-29 20:10                 ` Peter Zijlstra
2010-01-29 20:30                   ` Eric W. Biederman
2010-02-04 11:38                     ` Peter Zijlstra
2010-02-04 16:35                       ` Alan Stern
2010-02-04 16:41                         ` Peter Zijlstra [this message]
2010-02-04 18:37                           ` Alan Stern
2010-02-05 10:18                             ` Peter Zijlstra
2010-02-05 15:30                               ` Alan Stern
2010-02-05 15:41                                 ` Peter Zijlstra
2010-02-07  9:22                                   ` Dave Young
2010-02-08  3:08                                     ` Cong Wang
2010-02-08  3:14                                       ` Dave Young
2010-02-08  3:30                                         ` Cong Wang
2010-02-08  3:06                                 ` Cong Wang
2010-02-08 15:38                               ` Alan Stern
2010-02-04 16:46                         ` Peter Zijlstra
2010-02-04 18:40                           ` Alan Stern
2010-02-05  3:09                             ` Cong Wang
2010-02-05  4:06                               ` Alan Stern
2010-02-04 16:46                         ` Greg KH
2010-02-04 16:59                           ` Thomas Gleixner
2010-02-26 19:36                             ` Alan Stern
2010-02-26 20:54                               ` Thomas Gleixner
2010-02-05  3:43                       ` Cong Wang
2010-02-05  8:55                       ` Eric W. Biederman
2010-01-29 20:25         ` Eric W. Biederman
2010-01-30  5:30           ` Greg KH
2010-01-29 18:02   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1265301713.22001.128.camel@laptop \
    --to=peterz@infradead.org \
    --cc=Larry.Finger@lwfinger.net \
    --cc=akpm@linux-foundation.org \
    --cc=amwang@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@suse.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miles.lane@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox