[Top] [All Lists]

Re: [2.6.27-rc4] XFS i_lock vs i_iolock...

To: Christoph Hellwig <hch@xxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Lachlan McIlroy <lachlan@xxxxxxx>, Daniel J Blueman <daniel.blueman@xxxxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: [2.6.27-rc4] XFS i_lock vs i_iolock...
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 26 Aug 2008 15:35:08 -0400
In-reply-to: <20080826024547.GX5706@disturbed>
References: <6278d2220808221412x28f4ac5dl508884c8030b364a@xxxxxxxxxxxxxx> <20080825010213.GO5706@disturbed> <48B21507.9050708@xxxxxxx> <20080825035542.GR5706@disturbed> <1219647573.20732.28.camel@twins> <20080825215532.GB28188@xxxxxx> <20080826024547.GX5706@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Aug 26, 2008 at 12:45:47PM +1000, Dave Chinner wrote:
> XFS: prevent lockdep false positives when locking two inodes
> If we call xfs_lock_two_inodes() to grab both the iolock and
> the ilock, then drop the ilocks on both inodes, then grab
> them again (as xfs_swap_extents() does) then lockdep will
> report a locking order problem. This is a false positive.
> To avoid this, disallow xfs_lock_two_inodes() fom locking both
> inode locks at once - force calers to make two separate calls.
> This means that nested dropping and regaining of the ilocks
> will retain the same lockdep subclass and so lockdep will
> not see anything wrong with this code.

Looks good.  We probably don't need the #ifdef DEBUG as ASSERT is
debug-only anyway.

<Prev in Thread] Current Thread [Next in Thread>