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

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

quoted

On Wed, Apr 1, 2020 at 11:24 AM Alex Elder [off-list ref] wrote:

quoted

On 4/1/20 12:35 PM, Nick Desaulniers wrote:

quoted

quoted

Define FIELD_MAX(), which supplies the maximum value that can be
represented by a field value.  Define field_max() as well, to go
along with the lower-case forms of the field mask functions.

Signed-off-by: Alex Elder <redacted>
Acked-by: Jakub Kicinski <kuba@kernel.org>
---
v3: Rebased on latest netdev-next/master.

David, please take this into net-next as soon as possible.  When the
IPA code was merged the other day this prerequisite patch was not
included, and as a result the IPA driver fails to build.  Thank you.

  See: https://lkml.org/lkml/2020/3/10/1839

                                     -Alex

In particular, this seems to now have regressed into mainline for the 5.7
merge window as reported by Linaro's ToolChain Working Group's CI.
Link: https://github.com/ClangBuiltLinux/linux/issues/963

Is the problem you're referring to the result of a build done
in the midst of a bisect?

The fix for this build error is currently present in the
torvalds/linux.git master branch:
    6fcd42242ebc soc: qcom: ipa: kill IPA_RX_BUFFER_ORDER

Is that right? That patch is in mainline, but looks unrelated to what
I'm referring to.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fcd42242ebcc98ebf1a9a03f5e8cb646277fd78
From my github link above, the issue I'm referring to is a
-Wimplicit-function-declaration warning related to field_max.
6fcd42242ebc doesn't look related.

I'm very sorry, I pointed you at the wrong commit.  This one is
also present in torvalds/linux.git master:

  e31a50162feb bitfield.h: add FIELD_MAX() and field_max()

It defines field_max() as a macro in <linux/bitfield.h>, and
"gsi.c" includes that header file.

This was another commit that got added late, after the initial
IPA code was accepted.

Yep, that looks better.

quoted

quoted

I may be mistaken, but I believe this is the same problem I discussed
with Maxim Kuvyrkov this morning.  A different build problem led to
an automated bisect, which conluded this was the cause because it
landed somewhere between the initial pull of the IPA code and the fix
I reference above.

Yes, Maxim runs Linaro's ToolChain Working Group (IIUC, but you work
there, so you probably know better than I do), that's the CI I was
referring to.

I'm more concerned when I see reports of regressions *in mainline*.
The whole point of -next is that warnings reported there get fixed
BEFORE the merge window opens, so that we don't regress mainline.  Or
we drop the patches in -next.

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

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.

So I think the bot had your change when it ran, so still seeing a
failure is curious.  Unless I've misunderstood something.
-- 
Thanks,
~Nick Desaulniers