Re: linux-next: build failure after merge of the tip tree

[Ingo Molnar]

* Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/asm-generic/getorder.h:8,
>                  from arch/arm/include/asm/page.h:166,
>                  from arch/arm/include/asm/thread_info.h:14,
>                  from arch/arm/include/asm/percpu.h:16,
>                  from include/linux/irqflags.h:17,
>                  from arch/arm/include/asm/bitops.h:28,
>                  from include/linux/bitops.h:29,
>                  from include/linux/kernel.h:12,
>                  from include/asm-generic/bug.h:20,
>                  from arch/arm/include/asm/bug.h:60,
>                  from include/linux/bug.h:5,
>                  from include/linux/page-flags.h:10,
>                  from kernel/bounds.c:10:
> include/linux/log2.h: In function '__ilog2_u32':
> include/linux/log2.h:24:9: error: implicit declaration of function 'fls' [-Werror=implicit-function-declaration]
>    24 |  return fls(n) - 1;
>       |         ^~~
> 
> And so on ...
> 
> Caused by commit
> 
>   a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu variables")
> 
> interacting with commit
> 
>   00a30a5c9e6b ("arm: include asm/thread_info.h in asm/percpu.h")
> 
> (which was a fix of mine but now the equivalent is in Linus' tree as commit
> 
>   aa54ea903abb ("ARM: percpu.h: fix build error")
> )
> 
> I have reverted 00a30a5c9e6b since commit
> 
>   a6342915881a ("arm: Break cyclic percpu include")
> 
> (which precedes a21ee6055c30) acomplishes the same thing differently.
> Something will be required when this is merged with Linus' tree, though.

I've merged Linus's latest into tip:locking/core, keeping the simpler 
solution of a6342915881a and reducing the dependency hell.

Will push it all out hopefully later today (unrelated changes need 
more testing), from that point on there should be no conflict in 
-next.

My plan would be to send that resolution to Linus, under the 
assumption that a6342915881a is superior to the upstream aa54ea903abb 
solution.

Thanks,

	Ingo