[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081126125258.72336d33@rockhopper.limebrokerage.com>
Date: Wed, 26 Nov 2008 12:52:58 -0500
From: Dan Noé <dpn@...merica.net>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>
Subject: Re: Lockdep warning for iprune_mutex at shrink_icache_memory
On Wed, 26 Nov 2008 16:02:59 +0100
Peter Zijlstra <peterz@...radead.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists