On Apr 3, 2009, at 10:33 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx>
wrote:
On Mon, 2009-03-30 at 23:33 +0200, Peter Zijlstra wrote:
On Mon, 2009-03-30 at 14:26 -0700, Andrew Morton wrote:
On Wed, 18 Mar 2009 14:27:32 -0400
Eric Paris <eparis@xxxxxxxxxx> wrote:
I think this is a bandaide to shut up lockdep. I could either
figure
out lockdep classes and figure out how to reclassify inotify
locks since
I believe Nick is correct when he says inotify watches pin the
inode in
core so memory pressure can't evict it.
It's pretty sad to degrading the strength of the memory allocation
just
to squish a lockdep report.
Yeah, I agree, its the wrong thing to do. lockdep annotations really
aren't that hard -- also, you could also talk me through it.
static struct lock_class_key inotify_mutex_free;
/*
* here the inotify mutex gets moved to a different
* data structure with different locking semantics while
* holding inotify_mutex.
*/
lock_set_class(&foo->inotify_mutex.dep_map, "inotify_mutex_free",
&inotify_mutex_free, 0, _THIS_IP_);
Or when done without holding the inotify_mutex
/*
* here the inotify mutex gets moved to a different
* data structure with different locking semantics.
*/
lockdep_set_class(&foo->inotify_mutex, &inotify_mutex_free);
Is all there should be to it.
Thanks I'll try to send something soon.
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
