Re: [PATCH v3] bitfield.h: add FIELD_MAX() and field_max()

[Alex Elder]

On 4/1/20 5:26 PM, Nick Desaulniers wrote:
> On Wed, Apr 1, 2020 at 1:21 PM Alex Elder <elder@xxxxxxxxxx> wrote:
>>
>> On 4/1/20 2:54 PM, Nick Desaulniers wrote:
>>> On Wed, Apr 1, 2020 at 12:44 PM Alex Elder <elder@xxxxxxxxxx> wrote:
>>>>
>>>> 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.
> 
>>
>>> 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.
> 
>>> 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.

This is similar to the situation I discussed with Maxim this
morning.  A different failure (yes, DTC related) led to an
automated bisect process, which landed on my commit. And my
commit unfortunately has the the known issue that was later
corrected.

Maxim said this was what started the automated bisect:
===
+# 00:01:41 make[2]: *** [arch/arm64/boot/dts/ti/k3-am654-base-board.dtb] Error 2
+# 00:01:41 make[2]: *** [arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb] Error 2
+# 00:01:41 make[1]: *** [arch/arm64/boot/dts/ti] Error 2
+# 00:01:41 make: *** [dtbs] Error 2
===

> 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.

Thank you for following up.

					-Alex