On Mon, Mar 15, 2021 at 10:43:26AM -0700, Nick Desaulniers 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.
autosel does not send out "FAILED" emails. I only send them out for when a patch is cc: stable and is said to fix a older commit and the patch does not apply properly.
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.
I have a script like that, as does Guenter and Sasha. It's very computationaly expensive so I doubt we can reduce it down into something for scripts/ as it's only really needed for those of us maintaining stable kernels. It's not for a normal developer.
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.
I do re-run my script at times, it does require it to be run every once in a while. But again, who is going to care about this except me and Sasha?
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?
Maybe it will, mine might have picked it up, who knows, I haven't run it in a while. But as you say, because it fails to apply, that's a good reason for me to not backport it.
Anyway, I'm with Arnd here, I don't see the need for these as it's not fixing a regression and it's not a "simple" set of changes at all for no real users.
I do backport changes for newer versions of gcc for older stable kernels in order for my build systems to stay alive, but I never test with clang so I don't care about those systems :)
thanks,
greg k-h