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, 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/

\
 
 \ /
  Last update: 2006-10-18 18:09    [W:0.135 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site