Re: linux-next: manual merge of the kmemcheck tree

[Ingo Molnar <mingo@elte.hu>]

* Vegard Nossum <vegard.nossum@gmail.com> wrote:

> > thanks Stephen.
> >
> > I made this fixup too, yesterday, but solved it differently: i added 
> > kmemcheck_init() to before all early initcalls. I think that's the 
> > best solution for a fundamental debug feature like kmemcheck. (which 
> > could catch bugs in early initcalls as well) What do you think?
> >
> > i've pushed out a new auto-kmemcheck-next branch, so the conflicts 
> > should go away on your next iteration.
> 
> I'm sorry, I didn't have the chance to review your conflict 
> resolutions yet.
> 
> But I think it's correct to use an early_initcall() -- we do catch 
> errors even before kmemcheck_init(); the only purpose of 
> kmemcheck_init is to prevent additional CPUs from going up. And that's 
> exactly the purpose of "early initcalls", to run just before 
> additional CPUs are upped. (Yeah, I did point out in review that 
> "presmp_initcall" would have been a better name than "early", at least 
> for our purposes, however, it seems that the idea was rejected.)
> 
> Perhaps kmemcheck_init() is a misnomer as well. We are functional 
> before that, too. If you are looking for a different init() function, 
> there isn't one :-) Just an option parser, param_kmemcheck().

ok - could you please dig out Stephen's conflict resolution and send a 
patch against tip/kmemcheck? (or better yet, a pull request ;-)

	Ingo