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