linux-kernel - Re: [BUG] Lockdep warning with XFS on 2.6.22-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jun 2007 11:35:20 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	David Chinner <dgc@....com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Satyam Sharma <satyam.sharma@...il.com>,
	Johannes Weiner <hannes-kernel@...urebad.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	xfs-masters@....sgi.com
Subject: Re: [BUG] Lockdep warning with XFS on 2.6.22-rc6

On 26-06-2007 04:16, David Chinner wrote:
> On Mon, Jun 25, 2007 at 11:01:11PM +0200, Ingo Molnar wrote:
>> * Satyam Sharma <satyam.sharma@...il.com> wrote:
>>
>>> [ Ok, so we know that XFS wants to lock inodes in ascending inode 
>>> number order and not strictly the parent-first-child-second order that 
>>> rest of the fs/ code does, so that makes it difficult to teach lockdep 
>>> about this kind of lock ordering ... ]
> 
> It does both - parent-first/child-second and ascending inode # order,
> which is where the problem is. standing alone, these seem fine, but
> they don't appear to work when the child has a lower inode number
> than the parent.
...

>From xfs_inode.h:

/*
 * Flags for lockdep annotations.
 *
 * XFS_I[O]LOCK_PARENT - for operations that require locking two inodes
 * (ie directory operations that require locking a directory inode and
 * an entry inode).  The first inode gets locked with this flag so it
 * gets a lockdep subclass of 1 and the second lock will have a lockdep
 * subclass of 0.
 *
 * XFS_I[O]LOCK_INUMORDER - for locking several inodes at the some time
 * with xfs_lock_inodes().  This flag is used as the starting subclass
 * and each subsequent lock acquired will increment the subclass by one.
 * So the first lock acquired will have a lockdep subclass of 2, the
 * second lock will have a lockdep subclass of 3, and so on.
 */

I don't know xfs code, and probably miss something, but it seems
there could be some inconsistency: lockdep warning shows mr_lock/1
taken both before and after mr_lock (i.e. /0). According to the
above comment there should be always 1 before 0...

Cheers,
Jarek P.  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/