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


    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:


    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

    (and I don't see any filesystem hooks in user_path_parent() -- which is
    probably a good thing)


     \ /
      Last update: 2008-12-18 12:59    [W:0.020 / U:11.892 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site