On Fri, 8 Jun 2001, Bryan Henderson wrote:
> I'd like to see the single threaded guarantee to VFS routines revoked --
> not only the UP side of it, but the non-preemption as well. I have always
> been taught to assume that anything can happen between any two
> instructions, or even in the middle of one, unless I explicitly lock
> against it.
<shrug> VFS should be OK with that. IMO preemptive kernel patches are an
exercise in masturbation (bad algorithm that can be preempted at any point
is still a bad algorithm and should be fixed, not hidden), but the only
areas in VFS that still rely on BKL are locks.c, dquot.c and super.c. The
latter is fixed in the patches I'm feeding to Linus (OK, the pieces I'm
feeding to Linus make shifting the BKL down to method calls trivial). Other
two... Well, ask the poor guys who maintain them ;-)
There will be an interesting trickery around d_move() and ->d_parent -
right now any of the ->i_zombie on parent, dcache_lock and BKL
is enough to protect ->d_parent, but removing BKL from vfs_rename()
will make the last one insufficient. Most of the users of ->d_parent
have protection from ->i_zombie or from dcache_lock, but we'll have
to check all of them and possible add dcache_lock for those that rely
only on BKL. So that's a matter of auditing filesystems.
Other than that we have BKL shifted down to the places where mehtods are
called - ->rename() is the only exception.
> An "MP-safe" attribute that a filesystem driver can register for its VFS
> routines would be a good tool to get there.
No. There is no chance in hell to get the attribute-dependent locking into
the tree. It's one of the most reliable ways to get veto from Linus. And
don't expect any sympathy from me - I've seen too many dungpiles that
happened because of that idea.
In 2.5.early we'll need to move BKL into the methods themselves. Then it
becomes internal business of filesystems. End of story.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
