lkml.org 
[lkml]   [2008]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: configfs, dlm_controld & lockdep
On Thu, Dec 11, 2008 at 03:44:41PM +0100, Louis Rilling wrote:
> These warnings are known issues. This results from a lack of lockdep annotations
> in configfs. I must admit that I started to send patches for that a few months
> ago, and then could not find time to finish this work.
>
> The problem is a bit harder than just playing with I_MUTEX_CHILD, I_MUTEX_PARENT
> and I_MUTEX_NORMAL, since configfs recursively locks variable numbers
> (this can go to as many as the depth of the whole configfs tree) of
> config_group inodes during operations like mkdir(), rmdir(), and depend_item().
>
> I was working on two kinds of solutions:
> 1) insert lockdep_off()/lockdep_on() at the places of recursion,
> 2) separate default groups inode mutex classes according to their depth under
> the created group they belong to.
>
> People tend to reject any proposition like 1), but IIRC Joel was tending to
> accept it.
>
> Solution 2) does not work for depend_item(). This needs to rework the locking
> scheme of depend_item() by removing the variable lock recursion depth, and I
> think that it's doable thanks to the configfs_dirent_lock.
> Joel, what do you think about this?

I've been waiting for your patch for (1). I am wary of the (2)
approach. Not because it wouldn't work for mkdir(2) - I think it would.
But rmdir(2) has the same recursive locking, with far more importance
(live objects), and would print the same error.

Joel

--

Life's Little Instruction Book #267

"Lie on your back and look at the stars."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127


\
 
 \ /
  Last update: 2008-12-11 18:39    [W:0.164 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site