Re: [PATCH 0/8] linux-yocto: consolidated pull request

On Sat, Jul 3, 2021 at 6:02 PM Richard Purdie
[off-list ref] wrote:

Hi Bruce,

On Fri, 2021-07-02 at 11:13 -0400, bruce.ashfield@gmail.com wrote:

quoted

Here's the next consolidated pull request. It has two normal -stable updates
for 5.10 and 5.4, as well as the first steps in bringing 5.13 in as the
reference kernel (and then dropping 5.4 from master).

I've built and booted 5.13 as the default for qemu*, as well as building it
against both musl and glibc with the 5.13 libc-headers. I didn't run into
any issues, and neither did my AB runs (I'd like to think it is all the
other patches that have been sent as linux-yocto-dev moved foward that made
this relatively few patches now).

I've also ensured that AB intermittent fixes are in place for 5.13, so it
is safe from that point of vew as well. Folks without exlcit versions set,
will get 5.13, but it is already sane and fit for that purpose.

Obviously you can pick and chose what you need from this if there are issues,
and I'm around to trouble shoot anything that pops up.

Thanks for this. In general it looks good, there is just one failure worrying
me a bit:

https://autobuilder.yoctoproject.org/typhoon/#/builders/119/builds/425

which in diffoscope speak is:

http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210702-c3hu90kc/packages/diff-html/

You may wonder what this pull request has to do with a gcc-sanitisers failure?

If you don't speak dwarfish or elvish, it means that perf_branch_sample_type_shift
was declared on line 162 in one build and 182 in another. I wondered about a
bit flip however it is two bits and linux/perf_events.h has
perf_branch_sample_type_shift at line number 162 in 5.10 and 182 is 5.13 and that
file comes from linux-libc-headers. The logical conclusion is that one was built
with one header and the other, from the other header. Why/how this could happen
I simply don't know. The problem build came from sstate so there is no real
audit trail to follow :(.

I've done multiple header fixups with perf and libc-headers disagreeing, due to
captured copies being different from the uapi.

This is likely a variant of that.

... that being said, I've never seen anything that varied between
builds. It either
broke or it didn't.

This is libc-headers 5.13 and the 5.10 perf ?

Bruce

I'm not sure this blocks the pull request as the issue is probably somewhere else
and this just exposed it but any ideas on what happened are very welcome...

Cheers,

Richard

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II