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

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:1.308 / U:0.100 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site