Re: a Heisenbug tale (was: Re: arm crypto .S_shipped files sometimes get rebuilt randomly)

[Leonard Crestez <leonard.crestez@nxp.com>]

On Fri, 2018-03-09 at 09:45 +0000, Ard Biesheuvel wrote:
> On 8 March 2018 at 23:19, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> > On 2018-03-07 20:25, Leonard Crestez wrote:

> > > I am using a toolchain with a broken/old version of perl which doesn't
> > > include integer.pm and I noticed it triggers occasional build failures
> > > on arch/arm64/crypto/sha512-core.S_shipped. Workarounds are easy, but
> > > if the purpose of the .S_shipped is to avoid the need to have all
> > > dependencies on the build machine then something went wrong?

> > About a year ago, I debugged a very similar problem for a customer. The
> > build system (an OpenEmbedded clone) did something like
> > 
> > (1) git clone -n ...
> > (2) git checkout -q $somerev
> > (3) make foo_config
> > (4) make vmlinux
> > (5) make LOADADDR=0x1234 uImage
> > (6) make modules
> > ...
> > 
> > The symptoms, when the bug appeared, was that the kernel was built with
> > some version string "4.5.6-01234-g0abcdef", but the modules (both the
> > native kernel modules and those built externally using the linux-dev
> > package) ended up in /lib/modules/4.5.6-01234-g0abcdef-dirty.

> I had no idea that _shipped files were causing issues like this, and
> AFAICT, this is not specific to this use case in arch/arm/crypto,
> right?
> 
> Russell, would you mind if we removed the _shipped.S file here and
> just assume that perl is available?

It would be good for the fix to get into stable branches so that
downstreams don't each have to invent workarounds. Isn't it much easier
to do this with an #ifdef REGENERATE_ARM_CRYPTO_ASM? It might even be a
requirement for getting into stable.

The _shipped.S stuff can be removed later just for upstream.

--
Regards,
Leonard