From: Peter Zijlstra <peterz@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Lachlan McIlroy <lachlan@sgi.com>,
Daniel J Blueman <daniel.blueman@gmail.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, hch@lst.de
Subject: Re: [2.6.27-rc4] XFS i_lock vs i_iolock...
Date: Mon, 25 Aug 2008 08:59:33 +0200 [thread overview]
Message-ID: <1219647573.20732.28.camel@twins> (raw)
In-Reply-To: <20080825035542.GR5706@disturbed>
On Mon, 2008-08-25 at 13:55 +1000, Dave Chinner wrote:
> On Mon, Aug 25, 2008 at 12:12:23PM +1000, Lachlan McIlroy wrote:
> > Dave Chinner wrote:
> >> On Fri, Aug 22, 2008 at 10:12:59PM +0100, Daniel J Blueman wrote:
> >>> On 2.6.27-rc4 with various debug options enabled, lockdep claims lock
> >>> ordering issues with XFS [1] - easiest reproducer is just running
> >>> xfs_fsr. Mount options I was using were
> >>> 'nobarrier,noatime,nodiratime'.
> >>>
> >>> Thanks,
> >>> Daniel
> >>>
> >>> --- [1]
> >>>
> >>> =======================================================
> >>> [ INFO: possible circular locking dependency detected ]
> >>> 2.6.27-rc4-224c #1
> >>> -------------------------------------------------------
> >>> xfs_fsr/5763 is trying to acquire lock:
> >>> (&(&ip->i_lock)->mr_lock/2){--..}, at: [<ffffffff803ad8fc>] xfs_ilock+0x8c/0xb0
> >>>
> >>> but task is already holding lock:
> >>> (&(&ip->i_iolock)->mr_lock/3){--..}, at: [<ffffffff803ad915>]
> >>> xfs_ilock+0xa5/0xb0
> >>
> >> False positive. We do:
> >>
> >> xfs_lock_two_inodes(ip, tip, XFS_IOLOCK_EXCL | XFS_ILOCK_EXCL);
> >
> > Why not just change the above line to two lines:
> > xfs_lock_two_inodes(ip, tip, XFS_IOLOCK_EXCL);
> > xfs_lock_two_inodes(ip, tip, XFS_ILOCK_EXCL);
>
> Yeah, that'd work, but it implllies that we no longer allow
> xfs_lock_two_inodes() to take both inode locks at once.
How can you take two locks in one go? It seems to me you always need to
take them one after another, and as soon as you do that, you have
ordering constraints.
Of course it could be that doesn't matter, because there is another
serializing lock, but that isn't clear from this context.
> It
> would need a comment blaming^Wexplaining why lockdep requires
> us to do this, and then debug code in xfs_lock_two_inodes() to
> catch this when someone makes this mistake again in the future.
next prev parent reply other threads:[~2008-08-25 7:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-22 21:12 [2.6.27-rc4] XFS i_lock vs i_iolock Daniel J Blueman
2008-08-25 1:02 ` Dave Chinner
2008-08-25 2:12 ` Lachlan McIlroy
2008-08-25 3:55 ` Dave Chinner
2008-08-25 6:59 ` Peter Zijlstra [this message]
2008-08-25 21:55 ` Christoph Hellwig
2008-08-26 2:45 ` Dave Chinner
2008-08-26 19:35 ` Christoph Hellwig
2008-08-26 20:13 ` Daniel J Blueman
2008-08-26 21:34 ` Daniel J Blueman
2008-08-26 1:55 ` Dave Chinner
2008-08-25 6:57 ` 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=1219647573.20732.28.camel@twins \
--to=peterz@infradead.org \
--cc=daniel.blueman@gmail.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=lachlan@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xfs@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