lkml.org 
[lkml]   [2008]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item()
On 18/12/08 14:58 -0800, Joel Becker wrote:
> On Thu, Dec 18, 2008 at 01:28:28PM +0100, Peter Zijlstra wrote:
> > In fact, both (configfs) mkdir and rmdir seem to synchronize on
> > su_mutex..
> >
> > mkdir B/C/bar
> >
> > C.i_mutex
> > su_mutex
> >
> > vs
> >
> > rmdir foo
> >
> > parent(foo).i_mutex
> > foo.i_mutex
> > su_mutex
> >
> >
> > once holding the rmdir su_mutex you can check foo's user-content, since
> > any mkdir will be blocked. All you have to do is then re-validate in
> > mkdir's su_mutex that !IS_DEADDIR(C).
>
> We explicitly do not take any i_mutex locks after taking
> su_mutex. That's an ABBA risk. su_mutex protects the hierarchy of
> config_items. i_mutex protects the vfs view thereof.
> If you look in mkdir, we take su_mutex, get a new item from the
> client subsystem, then drop su_mutex. After that, we go about building
> our filesystem structure, using i_mutex where appropriate. More
> importantly is rmdir(2), where we use i_mutex in
> configfs_detach_group(), but are not holding su_sem. Only when
> configfs_detach_group() has successfully returned and we have torn down
> the filesystem structure do we take su_mutex and tear down the
> config_item structure.
> In fact, we're part of the way there. Check out that
> USET_DROPPING flag we set in detach_prep() while scanning for user
> objects. That flags us racing mkdir(2). When we are done with
> detach_prep(), we know that mkdir(2) calls racing behind us will do
> nothing until we safely lock them out with the locking in
> detach_group(). All mkdir(2) calls will have exited by the time we get
> the mutex, and no new mkdir(2) call can start because we have the mutex.
> Now look in detach_groups(). We drop the groups children before
> marking them DEAD. Louis' plan, I think, is to perhaps mark a group
> DEAD, disconnect it from the vfs, and then operate on its children. In
> this fashion, perhaps we can unlock the trailing lock like a normal VFS
> operation.
> This will require some serious auditing, however, because now
> vfs functions can get into the vfs objects behind us. And more vfs
> changes affect us. Whereas the current locking relies on the vfs's
> parent->child lock ordering only, something that isn't likely to be
> changed.

I've thought about such plan, but I'm not comfortable enough with the VFS to
tell how it could be done precisely, and whether it is safe to remove a whole
tree from the dcache by just unlinking its root. In particular, how could we
deal with racing operations under default groups? Should we setup a link from
any default group to its youngest non-default group ancestor? As Steven
suggested, looking at unmount might be interesting, but not today as far as I
am concerned.

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[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2008-12-19 11:31    [from the cache]
©2003-2011 Jasper Spaans