CONFIG_CC_STACKPROTECTOR v. armhf v3.13 mainline builds

Andy Whitcroft apw at canonical.com
Thu Dec 10 00:06:48 UTC 2015


On Wed, Dec 09, 2015 at 10:35:05AM -0800, Kamal Mostafa wrote:
> The automatic builds of my v3.13-stable have always resulted in these
> "all's well" emails:
> 
>         Subject:	Mainline Build v3.13.11-ckt29
>         Subject:	Mainline Build v3.13.11-ckt30
> 
> Until the most recent release that I just uploaded, which got:
> 
>         Subject:	Mainline Build v3.13.11-ckt31 failed
>         
>         Build architecture status:
>             binary-headers: good (rc=0)
>             amd64: good (rc=0)
>             i386: good (rc=0)
>             armhf: failed (rc=2)    <<<===
>             ppc64el: good (rc=0)
> 
> The armhf build[0] failed with:
>         
>         /home/kernel/COD/linux/arch/arm/boot/compressed/atags_to_fdt.c:96: undefined reference to `__stack_chk_fail'
>         /home/kernel/COD/linux/arch/arm/boot/compressed/atags_to_fdt.c:96: undefined reference to `__stack_chk_guard'
> 
> But what's really weird is, when I go look at the previous 3.13 mainline
> armhf build logs, I see that that error has ALWAYS been present[1]
> despite the "all's well" emails!

The emails were never (originally) "All is well" they were completion
notices.  As is evidenced by the complaints when they did not contain
.debs.

> Did the mainline builder somehow just recently gain the ability to
> notice this failure?

I have recently added support for detecting the result of each individual architecture
build and summarising them.  Each result is now suffixed either "suceeded"
or "failed".

> Cking correctly identified the "stack_chk" thing as being enabled by
> CONFIG_CC_STACKPROTECTOR.  (I can reproduce it with that, and not
> without).
> 
> I _was_ worried that this problem might affect ubuntu-trusty also, but
> now that I see its not even a new thing, I suppose that trusty is
> probably okay.
> 
> Any thoughts on these topics will be much appreciated:
> 
> 1. Why the builder suddenly notices this problem.
> 2. Why this problem occurs for armhf in 3.13 stable.
> 
>  -Kamal
> 
> [0]
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11-ckt31-trusty/BUILD.LOG.armhf
> 
> [1]
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11-ckt12-trusty/BUILD.LOG.armhf
> ...
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11-ckt30-trusty/BUILD.LOG.armhf

-apw




More information about the kernel-team mailing list