please set /proc/cpu/alignment=4 on Launchpad ARM buildd kernels

This probably should be changed in canonical-is-puppet for arch=armhf, not in launchpad-buildd, but I couldn't sort out how to reassign the bug successfully. :P

Well: we could do it in canonical-is-puppet, but I don't think there's a convenient init script already in place that we could tweak, so we'd need to spit out a new one, and that would then end up in a place that is pretty obscure to most people and invisible to anyone who doesn't work for Canonical. It might be more transparent to just do it in launchpad-buildd's init script, and that isn't *completely* logically wrong. It would certainly be easier.

I believe that we don't need to do this for the scalingstack case, because arm64 doesn't have the alignment trap feature at all. Please correct me if I'm wrong here.

> I believe that we don't need to do this for the scalingstack case,
> because arm64 doesn't have the alignment trap feature at all. Please
> correct me if I'm wrong here.

There is no CONFIG_ALIGNMENT_TRAP visible in the arm64 kernel config, so it
appears there's no need to configure it on arm64 hosts. I'm not sure if
that means that these unaligned accesses /will/ or /won't/ be trapped on an
arm64 kernel, but if they are trapped I guess that's not a problem you can
fix.

A quick test on the arm64 porter box suggests that they're trapped and
fixed up:

  (wily-arm64)cjwatson@rugby:~$ cat t.c
  #include <inttypes.h>
  #include <stdint.h>
  #include <stdio.h>

  void unaligned(uint64_t *x) { printf("x: %" PRIx64 "\n", *x); }

  int main(int argc, char **argv) {
          uint64_t a, b;
          a = 0x0123456789abcdef;
          b = 0xfedcba9876543210;
          unaligned((uint64_t *)((char *)&a + 1));
          return 0;
  }
  (wily-arm64)cjwatson@rugby:~$ gcc -O0 -g t.c -o t
  (wily-arm64)cjwatson@rugby:~$ ./t
  x: 100123456789abcd

So, I suppose we can do this, but it's going to cease being effective as
soon as we switch armhf to scalingstack, since this will be running on
top of arm64 kernels. My question is therefore: is it worth it given
that there would probably be some kind of cost and that the benefit
would be fairly short-term? If so, maybe somebody should look into how
an alignment trap that forces a signal on arm64 might work in more
detail.

On Mon, Nov 16, 2015 at 10:43:48PM -0000, Colin Watson wrote:
> A quick test on the arm64 porter box suggests that they're trapped and
> fixed up:

<snip>

> So, I suppose we can do this, but it's going to cease being effective as
> soon as we switch armhf to scalingstack, since this will be running on
> top of arm64 kernels. My question is therefore: is it worth it given
> that there would probably be some kind of cost and that the benefit
> would be fairly short-term? If so, maybe somebody should look into how
> an alignment trap that forces a signal on arm64 might work in more
> detail.

Talking with the hyperscale folks, it sounds like there's no straightforward
way to force SIGBUS to be raised on arm64.

So if ScalingStack is going to be running on arm64 kernels, then feel free
to consider this wontfix.

I do recall other issues where it seemed like it would be beneficial to run
armhf guest kernels in scalingstack instead of arm64 kernel + armhf
userspace. If that happened (which I know is currently not practical
because of the lack of sane armhf guest boot handling), it might be worth
revisiting this.

Looks like when running armv7 code on armv8, fixups do NOT occur, so this is Fix Released By Accident, IMO.

We definitely have alignment-related FTBFS and test failures in Ubuntu that don't reproduce in Debian, where they do fixups.