On Thu, Dec 18, 2008 at 08:26:48AM +0100, Peter Zijlstra wrote:
<snip>
It's not about breakneck speed, it's about living in the VFS.
But I think you get that later.
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).
I know it's hard, or I'd have sent you patches :-) In fact,
Louis tried to use the subclass bits to make this work to a depth of N
(where N was probably deep enough in practice). However, this creates
subclasses that don't get seen by the regular VFS locking - and the big
deal here is making sure configfs's use of i_mutex meshes with the VFS.
That is, his code made the warnings go away, but removed much of
lockdep's ability to see when we got the locking wrong.
This isn't about concurrency or speed. This is about safety
while configfs is attaching or (especially) detaching config_items from
the filesystem view it presents. When the VFS travels down a path, it
unlocks the trailing directory. We can't do that when tearing down
default groups, because we need to lock that small hunk and tear it out
atomically.
Oh, be nice :-)
You are absolutely right that turning off lockdep leaves the
possibility of complacency and bitrot. That's precisely why I didn't
like Louis' subclass solution - again, bitrot might go unnoticed.
Now, I know that I will be paying attention to the locking and
going over it with a fine-toothed comb. But I'd much rather have an
actual working lockdep analysis. Whether that means we find a way for
lockdep to describe what's happening here, or we find another way to
keep folks out of the tree we're removing, I don't care.
Joel
--
Life's Little Instruction Book #109
"Know how to drive a stick shift."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
--
