* Stephen Rothwell [off-list ref] wrote:

Hi all,

Today's linux-next merge of the tip-core tree got a conflict in
arch/x86/mach-voyager/voyager_smp.c between commit
92ab78315c638515d0e81b0c70b2082f713582d9 ("x86/Voyager: make it build and
boot") from Linus' tree and commit
552be871e67ff577ed36beb2f53d078b42304739 ("x86: pass in cpu number to
switch_to_new_gdt()") from the tip-core tree.

I used the resolution from tip/master (see below -worth checking that I 
got it right).  (Though I assume that there is no reason that the other 
uses of smp_processor_id() in voyager_smp_prepare_boot_cpu could be 
replaced by "cpu" as well?)

Thanks!

Note that the x86/Voyager code will have to be totally reworked ontop of the 
new x86 subarch code and that the cpumask logic there is largely obsolete 
(in the context of linux-next) and cannot be triggered via any 
Kconfig-reachable build mode anymore.

I've pushed out a next tip/auto-core-next branch so the conflict should 
disappear from your tree.

Note that there's another upcoming conflict, in arch/x86/mm/fault.c, due to 
this upstream commit from a few hours ago:

  9be260a: prevent kprobes from catching spurious page faults

This will conflict both with the pagefault cleanups in tip/x86/mm and with 
tip/kmemcheck so it's a non-trivial 3-way conflict. I've resolved the 
conflicts explicitly on the Git level and pushed out a freshly integrated 
x86-next, core-next and kmemcheck-next tree as well - so you should not be 
seeing conflicts in that area.

Note: take care because these trees also contain a lot of new stuff: the x86 
APIC and subarch rewrite, the shiny new percpu changes and cleanup and more. 
Let us know if you run into any trouble with them.

Thanks,

	Ingo