[lkml]   [2008]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


    Dr Louis Rilling Kerlabs
    Skype: louis.rilling Batiment Germanium
    Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes 35700 Rennes
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2008-12-19 11:31    [W:0.024 / U:2.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site