public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Cong Wang <amwang@redhat.com>,
	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>,
	akpm@linux-foundation.org
Subject: Re: [Patch 0/2] sysfs: fix s_active lockdep warning
Date: Fri, 29 Jan 2010 21:30:08 -0800	[thread overview]
Message-ID: <20100130053008.GD22459@suse.de> (raw)
In-Reply-To: <m1d40sr74d.fsf@fess.ebiederm.org>

On Fri, Jan 29, 2010 at 12:25:22PM -0800, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
> 
> > Heh, this whole mess is the very reason we didn't add lockdep support to
> > the driver core.  Nested devices that all look alike from the driver
> > core, are really different objects and the locking lifetimes are
> > separate, but lockdep can't see that.
> >
> > I suggest we just remove the original patch, as it seems to be causing
> > way too many problems.
> >
> > Any objections to that?
> 
> I think the hit rate for real problems has been about 25-50%.  Of the
> false positives a lot of those have been, code that is at least
> questionable.
> 
> Furthermore there are problems we can find this way that we won't know
> about any other way.  Unfortunately I haven't had much time to do
> anything kernel related lately, or I would have done more with this.
> My comment was about simply about finding a good way to increase the
> signal to noise ration so investigations can reasonably start with the
> presumption that code lockdep is complaining about real problems.
> 
> The deadlocks that we can hit in sysfs are very nasty to find, they
> have persisted for years, and they pop back up after they are fixed.
> So far the pain from lockdep annotations seems a lot lower.
> 
> Right now annotating with subclasses as Amerigo is attempting will work,
> and remove the false positives.  I was simply hoping to find a faster
> way to get there.
> 
> So yes, I do object to removing the original patch.  Let's put in the
> work to find a good path to remove the handful of cases that cause
> false positives.

Ok, that sounds good to me.

thanks,

greg k-h

  reply	other threads:[~2010-01-30  5:31 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
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 [this message]
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=20100130053008.GD22459@suse.de \
    --to=gregkh@suse.de \
    --cc=Larry.Finger@lwfinger.net \
    --cc=akpm@linux-foundation.org \
    --cc=amwang@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=ebiederm@xmission.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miles.lane@gmail.com \
    --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