[lkml]   [2008]   [Dec]   [18]   [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 Thu, 2008-12-18 at 12:56 +0100, Peter Zijlstra wrote:
    > On Thu, 2008-12-18 at 01:27 -0800, Joel Becker wrote:
    > > It's about the default_groups and how they build up and tear
    > > down small bits of tree.
    > > A simple creation of a config_item, a mkdir(2), is a normal VFS
    > > lock set and doesn't make lockdep unhappy. But if the new config_item
    > > has a default_group or two, they need locking too. Not so much on
    > > mkdir(2), but on rmdir(2).
    > Hohumm,..
    > So the problem is that mkdir() doesn't just create a single entity but a
    > whole tree:
    > configfs:/my_subsystem/$ mkdir foo
    > might result in:
    > foo/
    > foo/A/
    > foo/B/
    > foo/B/C/
    > which on rmdir foo you'd have to tear down, but only if its that exact
    > tree and not when say A has any user created directories.
    > VFS mkdir A/blah only synchronizes on A.i_mutex and checks S_DEAD to
    > avoid races with rmdir A - which would lock first parent(A).i_mutex and
    > then A.i_mutex before detaching A and marking it S_DEAD.
    > So what you're now doing is locking the full foo/ subtree in order to
    > check there is no user content and block mkdir/creat from generating any
    > - which is where the trouble comes from, right?
    > Like said on IRC, the whole populated thing made me think of
    > mount/umount (steven whitehouse seems to have had a similar notion).
    > You basically want to synchronize any user mkdir/creat against foo
    > instead of just the new parent so that rmdir foo can tell if there is
    > any such content without having to lock the whole subtree.
    > That would mean them locking both foo and the new parent (when they're
    > not one and the same). Trouble seems to be that vfs_mkdir() and such
    > already have their new parent locked, which means you cannot go about
    > locking foo anymore. But that would have resulted in a 3 deep
    > lock-chain.
    > (and I don't see any filesystem hooks in user_path_parent() -- which is
    > probably a good thing)
    > Bugger..

    In fact, both (configfs) mkdir and rmdir seem to synchronize on

    mkdir B/C/bar



    rmdir foo


    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).

    Does that sound plausible, or am I missing something obvious.. ?

     \ /
      Last update: 2008-12-18 13:31    [W:0.033 / U:38.084 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site