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

[Greg KH <gregkh@linuxfoundation.org>]

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