Re: 2.6.10-rc1-mm2: `key_init' multiple definition

[Chris Wright]

* Andrew Morton (akpm@xxxxxxxx) wrote:
> Chris Wright <chrisw@xxxxxxxx> wrote:
> >
> > * Andrew Morton (akpm@xxxxxxxx) wrote:
> > > Chris Wright <chrisw@xxxxxxxx> wrote:
> > > > I don't think this is needed.  The fix in Linus's tree should be
> > > > sufficient, which was simply:
> > > > 
> > > > -subsys_initcall(key_init);
> > > > +security_initcall(key_init);
> > > 
> > > Problem is with CONFIG_SECURITY=n, CONFIG_KEYS=y.  security_init() is a
> > > no-op and we go oops during the first usermodehelper call under
> > > driver_init().
> > 
> > Hmm, right.  Is it worth changing that?  Or do you prefer the explicit
> > approach you have?  init ordering is still messy, no matter how we slice
> > it.
> > 
> 
> The only fixes I can see are to do the explicit ordering as I've done, or
> to make CONFIG_KEYS depend on CONFIG_SECURITY or to create a new
> `exec_initcall' level whose mandate is "stuff which has to be done for a
> successful exec".

Or make sure security_init() still does security_initcalls when
CONFIG_SECURITY=n.

> The patch works.  I'm inclined to leave it as-is...

I was thinking of something similar to your exec_initcall idea.  Right
now, the early exec stuff is a no-op until do_initcalls(), which is pretty
late, because there's not any binfmt handlers registered.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/