On Mon, 15 Mar 2021 at 18:43, Nick Desaulniers ndesaulniers@google.com wrote:
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.
Not that I am aware of, no.
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.
So it was backported after it already been identified as being broken? That makes it even worse, imho.
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?
You haven't explained why all this effort is justified to begin with.
Who cares about being able to build 4.19 or 5.4 mainline with Clang 12 and IAS? I am aware that Clang enablement is a prerequisite for CFI and LTO etcetera, and so I am fully on board with this activity for current and future kernels.
Stable kernels are a different matter, though. I tend to get stable-kernel-rules.rst thrown in my face for proposing backports that aren't nearly as large or intrusive as this stuff, but for some reason, those rules do not seem to apply here.
So my suggestion would be to forget about 4.19 and 5.4 entirely for these changes, unless there is an obvious benefit to all consumers of these stable trees. Otherwise, exposing them to ongoing breakage like this is indefensible IMHO.