public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com
Subject: Re: [PATCH 05/11] XFS: Fix lock ASSERT on UP
Date: Wed, 21 Mar 2012 11:44:39 +1100	[thread overview]
Message-ID: <20120321004439.GU5091@dastard> (raw)
In-Reply-To: <20120320022812.GA30406@tassilo.jf.intel.com>

On Mon, Mar 19, 2012 at 07:28:12PM -0700, Andi Kleen wrote:
> > So this means we only ever check that the spinlock is held when
> > lockdep is turned on instead of whenever CONFIG_XFS_DEBUG is set?
> 
> You should regularly test with lockdep anyways.

I do. Once or twice a release cycle I'll do a test cycle with
lockdep enabled. i don't use it on day-to-day tst cycles because of
it's overhead, and well, I understand the lock ordering of most of
the code I'm modifying....

> If you don't you clearly
> have a testing gap. lockdep is likely to find many more locking bugs
> than any of your very sparse manual annotations.

That's not true. Lockdep validates lock order but it doesn't find
race conditions. Nor does lockdep tell us that the correct lock is
held when entering the function. Nor does it tell us that the state
of a RCU freed object is correct when it is reallocated out of the
kmem_cache it belongs to. These things need manual annotations, and
they find more problems during development than lockdep does.

Not to mention that we have to annotate our read/write locks with
extra state when CONFIG_XFS_DEBUG is enabled to ensure that the lock
mode is correct because rwsems can't tell us the difference between
a read hold and a write hold.

Hell, we only check the inode lock state in about 40 different
locations via xfs_isilocked(), but many of these locations have
multiple callers. e.g.  there's a check in xfs_trans_ijoin(), and it
has about 60 callers.  So the "very sparse manual annotations" for
locking behaviour in XFS are far more comprehensive than you claim
and catch many more problems early in development under
CONFIG_XFS_DEBUG than lockdep is even aware exists....

> > That means it will rarely get checked during development instead of
> > all the time. That's not an improvement IMO....
> 
> It's an improvement that an !CONFIG_SMP && CONFIG_XFS_DEBUG kernel
> will not blow up anymore.

<shrug>

Whatever, it's not worth arguing over. There's only two places that
XFS uses spin_is_locked(), and there are other checks around it that
will catch the same race conditions with CONFIG_XFS_DEBUG enabled,
so go ahead and use lockdep for them.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2012-03-21  0:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-16 19:00 Tree sweep for spin_is_locked misuses and start warning about it Andi Kleen
2012-03-16 19:00 ` [PATCH 01/11] block: use lockdep_assert_held for queue locking Andi Kleen
2012-03-16 19:00 ` [PATCH 02/11] sgi-xp: Use lockdep_assert_held Andi Kleen
2012-03-16 19:11   ` Robin Holt
2012-03-16 19:00 ` [PATCH 03/11] ada152x: Remove broken usage of spin_is_locked Andi Kleen
2012-03-16 19:00 ` [PATCH 04/11] staging/zmem: Use lockdep_assert_held instead " Andi Kleen
2012-03-16 19:00 ` [PATCH 05/11] XFS: Fix lock ASSERT on UP Andi Kleen
2012-03-19 22:47   ` Dave Chinner
2012-03-20  2:28     ` Andi Kleen
2012-03-21  0:44       ` Dave Chinner [this message]
2012-03-16 19:00 ` [PATCH 06/11] huge-memory: Use lockdep_assert_held Andi Kleen
2012-03-16 19:44   ` Andrea Arcangeli
2012-03-16 21:18     ` Hugh Dickins
2012-03-16 19:01 ` [PATCH 07/11] futex: Use lockdep_assert_held() for lock checking Andi Kleen
2012-03-16 19:01 ` [PATCH 08/11] irda: remove spin_is_locked Andi Kleen
2012-03-16 19:01 ` [PATCH 09/11] usb: gadget: f_fs: Remove lock is held before freeing checks Andi Kleen
2012-03-16 19:01 ` [PATCH 10/11] smsc911x: Use lockdep_assert_held instead of home grown buggy construct Andi Kleen
2012-03-16 19:01 ` [PATCH 11/11] checkpatch: Check for spin_is_locked Andi Kleen
2012-03-16 19:22   ` Joe Perches
2012-03-16 20:14     ` Andi Kleen

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=20120321004439.GU5091@dastard \
    --to=david@fromorbit.com \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs-masters@oss.sgi.com \
    /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