Date: Wed, 26 Nov 2008 12:52:58 -0500
From: Dan =?UTF-8?B?Tm/DqQ==?= <dpn@isomerica.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Chinner <david@fromorbit.com>, linux-kernel@vger.kernel.org,
       Christoph Hellwig <hch@infradead.org>
Subject: Re: Lockdep warning for iprune_mutex at shrink_icache_memory
Message-ID: <20081126125258.72336d33@rockhopper.limebrokerage.com>
In-Reply-To: <1227711779.4454.184.camel@twins>
References: <20081125064357.5a4f1420@tuna>
	<20081126072625.GH6291@disturbed>
	<1227711779.4454.184.camel@twins>
Organization: isomerica.net
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1303
Lines: 37

On Wed, 26 Nov 2008 16:02:59 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> The thing to do is re-annotate the inode locks whenever the inode
> changes data-structure, much like we do in unlock_new_inode().
> 
> So for each stage in the inode's life-cycle you need to create a key
> for each lock, such as:
> 
> struct lock_class_key xfs_active_inode_ilock;
> struct lock_class_key xfs_deleted_inode_ilock;
> ...
> 
> and on state change do something like:
> 
>   BUG_ON(rwsem_is_locked(&xfs_ilock->mrlock));
> 
>   init_rwsem(&xfs_ilock->mrlock);
>   lockdep_set_class(&xfs_ilock->mrlock, &xfs_deleted_inode_ilock);

This seems to make sense, based on my understanding and reading of the
lockdep documentation.  It looks like the first step is to add callbacks
for state change, and then add XFS specific callbacks that set the
lockdep class.  I would love to work on a patch, with some guidance.

Thanks,
Dan

-- 
                    /--------------- - -  -  -   -   -
                   |  Dan Noé
                   |  http://isomerica.net/~dpn/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/