Messages in this thread | | | From | Nick Desaulniers <> | Date | Wed, 1 Apr 2020 12:54:43 -0700 | Subject | Re: [PATCH v3] bitfield.h: add FIELD_MAX() and field_max() |
| |
On Wed, Apr 1, 2020 at 12:44 PM Alex Elder <elder@linaro.org> wrote: > > On 4/1/20 2:13 PM, Nick Desaulniers wrote: > > On Wed, Apr 1, 2020 at 11:24 AM Alex Elder <elder@linaro.org> wrote: > >> > >> On 4/1/20 12:35 PM, Nick Desaulniers wrote: > >>>> 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 <elder@linaro.org> > >>>> 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.
> > >> 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
| |