On Wed, Apr 1, 2020 at 1:21 PM Alex Elder [off-list ref] wrote:

On 4/1/20 2:54 PM, Nick Desaulniers wrote:

quoted

On Wed, Apr 1, 2020 at 12:44 PM Alex Elder [off-list ref] wrote:

quoted

Can you tell me where I can find the commit id of the kernel
that is being built when this error is reported?  I would
like to examine things and build it myself so I can fix it.
But so far haven't found what I need to check out.

From the report: https://groups.google.com/g/clang-built-linux/c/pX-kr_t5l_A

That link doesn't work for me.

Sigh, second internal bug filed against google groups this
week...settings look correct but I too see a 404 when in private
browsing mode.

quoted

Configuration details:
rr[llvm_url]="https://github.com/llvm/llvm-project.git"
rr[linux_url]="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
rr[linux_branch]="7111951b8d4973bda27ff663f2cf18b663d15b48"

That commit is just the one in which Linux v5.6 is tagged.
It doesn't include any of this code (but it's the last
tagged release that current linus/master is built on).

It doesn't answer my question about what commit id was
used for this build, unfortunately.

7111951b8d4973bda27ff663f2cf18b663d15b48 *is* the commit id that was
used for the build.  It sync'd the mainline tree at that commit.

quoted

the linux_branch looks like a SHA of what the latest ToT of mainline
was when the CI ran.

I was suspecting that maybe there was a small window between the
regression, and the fix, and when the bot happened to sync.  But it
seems that: e31a50162feb352147d3fc87b9e036703c8f2636 landed before
7111951b8d4973bda27ff663f2cf18b663d15b48 IIUC.

Yes, this:
  e31a50162feb bitfield.h: add FIELD_MAX() and field_max()
landed about 200 commits after the code that needed it.

So there's a chance the kernel that got built was somewhere
between those two, and I believe the problem you point out
would happen in that case.  This is why I started by asking
whether it was something built during a bisect.

It's still not clear to me what happened here.  I can explain
how this *could* happen, but I don't believe problem exists
in the latest upstream kernel commit.

Is there something else you think I should do?

mainline is hosed for aarch64 due to some dtc failures.  I'm not sure
how TCWG's CI chooses the bisection starting point, but if mainline
was broken, and it jumped back say 300 commits, then the automated
bisection may have converged on your first patch, but not the second.

I just checked out mainline @ 7111951b8d4973bda27ff663f2cf18b663d15b48
and couldn't reproduce, so I assume the above is what happened.  So
sorry for the noise, I'll go investigate the dtc failure.  Not sure
how that skipped -next coverage.
-- 
Thanks,
~Nick Desaulniers