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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
