Messages in this thread | | | Date | Wed, 18 Oct 2006 09:32:08 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: dealing with excessive includes |
| |
On Wed, 18 Oct 2006, Al Viro wrote: > > Actually, after reading that code I suspect that get_fs_excl() in there > is the wrong thing to do. Why? Because the logics is all wrong. > > Look what we do under lock_super(). There are two things: ->remount_fs() > and ->write_super(). Plus whatever low-level filesystems are using > lock_super() for.
I think this all boils down to the fact that "lock_super()" really is a very old and broken interface. It pretty much harks back to the original filesystem code, and yes, every "lock_super()" _should_ probably be replaced by a lower-level lock.
I think ext2 was already fixed to use its own spinlocks for bitmap accesses, although it looks like somebody re-introduced "lock_super()" there for xattr handling.
[ Which in turn is probably just a bug, since nothing else uses it, so having a single lock_user() in all of ext2 is almost certainly totally pointless - there is nothing that it actually _protects_ against. I guess it protects against "sync()", but that's pretty much it. ]
That said, I'd rather do any lock_super() cleanup totally _independently_ of a include file cleanup.
So since it's clearly not performance-critical, how about just making it be out-of-line in fs/super.c, and turn the header file into just a declaration?
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |