On Tue, 2008-05-20 at 15:13 -0700, Arjan van de Ven wrote: > On Tue, 20 May 2008 14:56:39 -0700 > Joel Becker <[EMAIL PROTECTED]> wrote: > > > On Tue, May 20, 2008 at 09:58:10AM -0700, Arjan van de Ven wrote: > > > On Tue, 20 May 2008 18:33:20 +0200 > > > Louis Rilling <[EMAIL PROTECTED]> wrote: > > > > > > > The following patches fix lockdep warnings resulting from > > > > (correct) recursive locking in configfs. > > > > > > > > ... > > > > > > > > Since lockdep does not handle such correct recursion, the idea is > > > > to insert lockdep_off()/lockdep_on() for inode mutexes as soon as > > > > the level of recursion of the I_MUTEX_PARENT -> I_MUTEX_CHILD > > > > dependency pattern increases. > > > > > > I'm... not entirely happy with such a solution ;( > > > > > > there must be a better one. > > > > We're trying to find it. I really appreciate Louis taking the > > time to approach the issue. His first pass was to add 1 to > > MUTEX_CHILD for each level of recursion. This has a very tight limit > > (4 or 5 levels), but probably covers all users that exist and perhaps > > all that ever will exist. However, it means passing the lockdep > > annotation level throughout the entire call chain across multiple > > files. It was definitely less readable. > > This approach takes a different tack - it's very readable, but > > it assumes that the currently correct locking will always remain so - > > a particular invariant that lockdep exists to verify :-) > > Louis, what about sticking the recursion level on > > configfs_dirent? That is, you could add sd->s_level and then use it > > when needed. THis would hopefully avoid having to pass the level as > > an argument to every function. Then we can go back to your original > > scheme. If they recurse too much and hit the lockdep limit, just > > rewind everything and return -ELOOP. > > you can also make a new lockdep key for each level... not pretty but it > works
Yeah, that is what I've done in the past for trees: http://programming.kicks-ass.net/kernel-patches/concurrent-pagecache/23-rc1-rt/radix-concurrent-lockdep.patch _______________________________________________ Ocfs2-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-devel
