On Wed, Oct 18, 2006 at 08:04:24AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 18 Oct 2006, Al Viro wrote:
> >
> > +#define lock_super(x) do { \
> > + struct super_block *sb = x; \
> > + get_fs_excl(); \
> > + mutex_lock(&sb->s_lock); \
> > +} while(0)
>
> Don't do this. The "x" passed in may be "sb", and then you end up with
> bogus code.
*duh*
> I think the solution to these kinds of things is either
> - just bite the bullet, and make it out-of-line. A function call isn't
> that expensive, and is sometimes actually cheaper due to I$ issues.
> - have a separate trivial header file, and only include it for people who
> actually need these things (very few files, actually - it's usually
> just one file per filesystem)
>
> In this case, since it's _so_ simple, and since it's _so_ specialized, I
> think #2 is the right one. Normally, uninlining would be.
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 would argue that we want to move get_fs_excl() down to the places in
->write_super() that actually want to do something deserving it. And
to be honest, I'm not at all sure that lock_super() should survive
at upper layers, but that's a longer story...
-
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]
