On Thu, Dec 18, 2008 at 07:00:17PM +0100, Louis Rilling wrote:
> >From inside configfs it is not possible to serialize those recursive
> locking with a top-level one, because mkdir() and rmdir() are already
> called with inodes locked by the VFS. So using some
> mutex_lock_nest_lock() is not an option.
> I am proposing two solutions:
> 1) one that wraps recursive mutex_lock()s with
> 2) (as suggested earlier by Peter Zijlstra) one that puts the
> i_mutexes recursively locked in different classes based on their
> depth from the top-level config_group created. This
> induces an arbitrary limit (MAX_LOCK_DEPTH - 2 == 46) on the
> nesting of configfs default groups whenever lockdep is activated
> but this limit looks reasonably high. Unfortunately, this also
> isolates VFS operations on configfs default groups from the others
> and thus lowers the chances to detect locking issues.
> Nobody likes solution 1), what I can understand.
Me too :-P
> This patch implements solution 2). However lockdep is still not happy with
> configfs_depend_item(). Next patch reworks the locking of
> configfs_depend_item() and finally makes lockdep happy.
Can you change this to provide non-lockdep versions of
functions? We don't want "#ifdef CONFIG_LOCKDEP" everywhere. What we
want is the code to call functions unconditionally, and the functions to
do nothing if lockdep is not enabled. Like: