Messages in this thread | | | Subject | Re: [PATCH] configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item() | From | Peter Zijlstra <> | Date | Thu, 18 Dec 2008 13:28:28 +0100 |
| |
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 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).
Does that sound plausible, or am I missing something obvious.. ?
| |