Messages in this thread | | | Date | Wed, 18 Oct 2006 17:06:09 +0100 | From | Al Viro <> | Subject | Re: dealing with excessive includes |
| |
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 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/
| |