Re: configfs, dlm_controld & lockdep

[Louis Rilling <Louis.Rilling@kerlabs.com>]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

On 11/12/08  9:34 -0800, Joel Becker wrote:
> 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.

??

(2) is fine for both mkdir() and rmdir(), since they both lock inodes'
mutexes along paths, and only paths. The problem is depend_item().

Anyway, I'll post patches based on (1) and later I'll propose patches based
on (2).

Louis

-- 
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]