Re: ARCH=arm LLVM_IAS=1 patches for 5.10, 5.4, and 4.19

[Nick Desaulniers <ndesaulniers@google.com>]

On Mon, Mar 15, 2021 at 3:37 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Note that the 5.4 Thumb2 build is still broken today because
> it carries
>
> eff8728fe698 vmlinux.lds.h: Add PGO and AutoFDO input sections
>
> but does not carry
>
> f77ac2e378be ARM: 9030/1: entry: omit FP emulation for UND exceptions
> taken in kernel mode
>
> which is tagged as a fix for the former patch, and landed in v5.11.
> (Side question: anyone have a clue why the patch in question was never
> selected for backporting?)

I will follow up on the rest, but some quick forensics.

f77ac2e378be ("ARM: 9030/1: entry: omit FP emulation for UND
exceptions taken in kernel mode")

was selected for inclusion into 5.10.y on 2020-12-20:
https://lore.kernel.org/stable/20201228125038.405690346@linuxfoundation.org/

I actually don't have a
Subject: FAILED: patch "[PATCH] <oneline>" failed to apply to X.YY-stable tree
email for this, which seems unusual. I don't know if one wasn't sent,
or message engine had a hiccup or what, so I don't know if it simply
failed to apply to older trees.  Ard, did you as the author receive
such an email?  Usually everyone cc'ed on the patch gets such emails
from autosel, it looks like.

Then *later*
eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
was sent to stable on 2021-01-13:
https://lore.kernel.org/stable/20210113185758.GA571703@ubuntu-m3-large-x86/

I was cc'ed on both, and didn't notice or forgot that one had
additional fixes necessary.  My mistake.

I think one way to avoid that in the future in a semi automated
fashion would be to have an in tree script like checkpatch that given
a sha from mainline would check git log for any Fixes tag that may
exist on subsequent patches.  Then it should be possible for any patch
that itself is backported (contains "commit XXX upstream") to be fed
in when auto selected or submitted to stable (or before then) to check
for new fixes.  Probably would still need to be run periodically, as
Fixes: aren't necessarily available when AutoSel runs.  For the
toolchain, we have a bot that watches for reverts for example, but
non-standard commit messages denoting one patch fixes another makes
this far from perfect.  Would still need to be run periodically,
because if a Fixes: exists, but hasn't been merged yet, it could get
missed.

Though I'm curious how the machinery that picks up Fixes: tags works.
Does it run on a time based cadence?  Is it only run as part of
AutoSel, but not for manual backports sent to the list?  Would it have
picked up on f77ac2e378be at some point?

f77ac2e378be doesn't apply cleanly to linux-5.4.y. There's a conflict
in arch/arm/vfp/vfphw.S due to 5.4 missing
commit 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available")
which is one of the patches I sent in the 5.4 series in this thread.
That was 1 of a 3 patch series:
https://lore.kernel.org/linux-arm-kernel/cover.1593205699.git.stefan@agner.ch/

Should I separate out just those 3 and f77ac2e378be and send that for
5.4, or manually backport just f77ac2e378be and note in the commit
message the conflict?

eff8728fe698 was sent back to 4.4, so if it's easy to reproduce the
observed failure, we can test to see if branches older than 5.4 are
also affected.  It sounds like eff8728fe698 was merged 2021-01-15, so
THUMB2 would have been broken since then. I didn't see any reports on
https://lore.kernel.org/stable/20210113185758.GA571703@ubuntu-m3-large-x86/;
was this reported elsewhere earlier? Did automated testing help find
this, or was it found manually just now?  I'm curious if there's a way
to expand our automated coverage since this eluded us?

commit 3ce47d95b734 ("powerpc: Handle .text.{hot,unlikely}.* in linker script")
is the only other commit in mainline that refers to eff8728fe698, but
doesn't use that in its Fixes tag.  I don't see any other follow up
patches (yet! *ducks*).
--
Thanks,
~Nick Desaulniers