[lkml]   [2006]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.116 / U:2.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site