Received: with ECARTIS (v1.0.0; list xfs); Sun, 24 Aug 2008 20:54:28 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE
	autolearn=no version=3.3.0-r574664
Received: from cuda.sgi.com ([192.48.176.15])
	by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m7P3sP25030847
	for <xfs@oss.sgi.com>; Sun, 24 Aug 2008 20:54:25 -0700
X-ASG-Debug-ID: 1219636546-30f603380000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 48C521A3F54F
	for <xfs@oss.sgi.com>; Sun, 24 Aug 2008 20:55:47 -0700 (PDT)
Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id DTjUunKGlkAswP0S for <xfs@oss.sgi.com>; Sun, 24 Aug 2008 20:55:47 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmkDACTHsUh5LD0wiGdsb2JhbACSLQEBAQ8goAuBaw
X-IronPort-AV: E=Sophos;i="4.32,264,1217773800"; 
   d="scan'208";a="179554997"
Received: from ppp121-44-61-48.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.61.48])
  by ipmail01.adl6.internode.on.net with ESMTP; 25 Aug 2008 13:25:45 +0930
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1KXTB8-0002ds-La; Mon, 25 Aug 2008 13:55:42 +1000
Date: Mon, 25 Aug 2008 13:55:42 +1000
From: Dave Chinner <david@fromorbit.com>
To: Lachlan McIlroy <lachlan@sgi.com>
Cc: Daniel J Blueman <daniel.blueman@gmail.com>,
        Linux Kernel <linux-kernel@vger.kernel.org>, xfs@oss.sgi.com,
        hch@lst.de
X-ASG-Orig-Subj: Re: [2.6.27-rc4] XFS i_lock vs i_iolock...
Subject: Re: [2.6.27-rc4] XFS i_lock vs i_iolock...
Message-ID: <20080825035542.GR5706@disturbed>
Mail-Followup-To: 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
References: <6278d2220808221412x28f4ac5dl508884c8030b364a@mail.gmail.com> <20080825010213.GO5706@disturbed> <48B21507.9050708@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48B21507.9050708@sgi.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146]
X-Barracuda-Start-Time: 1219636548
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -2.02
X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.3640
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV 0.91.2/8083/Sun Aug 24 17:48:23 2008 on oss.sgi.com
X-Virus-Status: Clean
X-archive-position: 17701
X-ecartis-version: Ecartis v1.0.0
Sender: xfs-bounce@oss.sgi.com
Errors-to: xfs-bounce@oss.sgi.com
X-original-sender: david@fromorbit.com
Precedence: bulk
X-list: xfs

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. 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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com