On Mon, 15 Mar 2021 at 18:43, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote:
>
> On Mon, Mar 15, 2021 at 3:37 AM Ard Biesheuvel <ardb@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx/
>
> 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@xxxxxxxx/
>
> 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.
--
Ard.
> 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
