Dear stable kernel maintainers, Please consider merging the following patch series'. They enable clang's integrated assembler to be used to assemble ARCH=arm kernels back to linux-4.19.y. This is analogous to previous series' sent for LLVM_IAS=1 support, but focused on ARM (32b).
Below is the list of commits in each series, in the form <first tag of mainline containing sha> <sha12> <commit oneline>
For 5.10: v5.11-rc1 3c9f5708b7ae ("ARM: 9029/1: Make iwmmxt.S support Clang's integrated assembler") v5.11-rc1 0b1674638a5c ("ARM: assembler: introduce adr_l, ldr_l and str_l macros") v5.11-rc1 67e3f828bd4b ("ARM: efistub: replace adrl pseudo-op with adr_l macro invocation")
For 5.4: v5.5-rc1 b4d0c0aad57a ("crypto: arm - use Kconfig based compiler checks for crypto opcodes") v5.5-rc1 9f1984c6ae30 ("ARM: 8929/1: use APSR_nzcv instead of r15 as mrc operand") v5.5-rc1 790756c7e022 ("ARM: 8933/1: replace Sun/Solaris style flag on section directive") v5.6-rc1 42d519e3d0c0 ("kbuild: Add support for 'as-instr' to be used in Kconfig files") v5.7-rc1 7548bf8c17d8 ("crypto: arm/ghash-ce - define fpu before fpu registers are referenced") v5.8-rc1 d85d5247885e ("ARM: OMAP2+: drop unnecessary adrl") v5.8-rc1 a780e485b576 ("ARM: 8971/1: replace the sole use of a symbol with its definition") v5.8-rc1 b744b43f79cc ("kbuild: add CONFIG_LD_IS_LLD") v5.9-rc1 a6c30873ee4a ("ARM: 8989/1: use .fpu assembler directives instead of assembler arguments") v5.9-rc1 ee440336e5ef ("ARM: 8990/1: use VFP assembler mnemonics in register load/store macros") v5.9-rc1 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available") v5.10-rc1 54781938ec34 ("crypto: arm/sha256-neon - avoid ADRL pseudo instruction") v5.10-rc1 0f5e8323777b ("crypto: arm/sha512-neon - avoid ADRL pseudo instruction") v5.11-rc1 28187dc8ebd9 ("ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD")
Then 3c9f5708b7ae from the 5.10 series is applied (0b1674638a5c and 67e3f828bd4b were not necessary). 28187dc8ebd9 had previously been picked up into 5.10 automatically. There was a minor conflict in 2cbd1cc3dcd3 due to 5.10 missing 8a90a3228b6a ("arm: Unplug KVM from the build system").
b744b43f79cc and 28187dc8ebd9 are more specifically for allmodconfig support than strictly LLVM_IAS=1.
For 4.19: v4.20-rc1 d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support") v4.20-rc1 f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders") v5.1-rc1 baf2df8e15be ("ARM: 8827/1: fix argument count to match macro definition") v5.1-rc1 32fdb046ac43 ("ARM: 8828/1: uaccess: use unified assembler language syntax") v5.1-rc1 eb7ff9023e4f ("ARM: 8829/1: spinlock: use unified assembler language syntax") v5.1-rc1 a216376add73 ("ARM: 8841/1: use unified assembler in macros") v5.1-rc1 e44fc38818ed ("ARM: 8844/1: use unified assembler in assembly files") v5.2-rc1 fe09d9c641f2 ("ARM: 8852/1: uaccess: use unified assembler language syntax") v5.2-rc1 3ab2b5fdd1d8 ("ARM: mvebu: drop unnecessary label") v5.2-rc1 969ad77c14ab ("ARM: mvebu: prefix coprocessor operand with p") v5.3-rc1 3fe1ee40b2a2 ("ARM: use arch_extension directive instead of arch argument") v5.4-rc3 3aa6d4abd4eb ("crypto: arm/aes-ce - build for v8 architecture explicitly")
Then the entire 5.4 series is applied on top. 3fe1ee40b2a2 had a minor conflict due to 4.19 missing 2997520c2d4e ("ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs").
I plan to send some follow ups; I need to do another pass to find what we may need in addition when setting CONFIG_THUMB2_KERNEL=y (non-default), there are two patches working their way through the ARM maintainer's tree needed for allmodconfig (https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9061/1 and https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9062/1) and v4.19.y has one more issue I need to look into (https://github.com/ClangBuiltLinux/linux/issues/1329) that has been cleaned up by a 7 patch series that landed in v5.2-rc1, but on first glance I suspect might be an assembler bug for us to fix.
These series will be used in Android and ChromeOS. We're also ready to wire up CI coverage for LLVM_IAS=1 ARCH=arm for these branches.
On Thu, Mar 11, 2021 at 11:32:22AM -0800, Nick Desaulniers wrote:
Dear stable kernel maintainers, Please consider merging the following patch series'. They enable clang's integrated assembler to be used to assemble ARCH=arm kernels back to linux-4.19.y. This is analogous to previous series' sent for LLVM_IAS=1 support, but focused on ARM (32b).
Below is the list of commits in each series, in the form <first tag of mainline containing sha> <sha12> <commit oneline>
For 5.10: v5.11-rc1 3c9f5708b7ae ("ARM: 9029/1: Make iwmmxt.S support Clang's integrated assembler") v5.11-rc1 0b1674638a5c ("ARM: assembler: introduce adr_l, ldr_l and str_l macros") v5.11-rc1 67e3f828bd4b ("ARM: efistub: replace adrl pseudo-op with adr_l macro invocation")
For 5.4: v5.5-rc1 b4d0c0aad57a ("crypto: arm - use Kconfig based compiler checks for crypto opcodes") v5.5-rc1 9f1984c6ae30 ("ARM: 8929/1: use APSR_nzcv instead of r15 as mrc operand") v5.5-rc1 790756c7e022 ("ARM: 8933/1: replace Sun/Solaris style flag on section directive") v5.6-rc1 42d519e3d0c0 ("kbuild: Add support for 'as-instr' to be used in Kconfig files") v5.7-rc1 7548bf8c17d8 ("crypto: arm/ghash-ce - define fpu before fpu registers are referenced") v5.8-rc1 d85d5247885e ("ARM: OMAP2+: drop unnecessary adrl") v5.8-rc1 a780e485b576 ("ARM: 8971/1: replace the sole use of a symbol with its definition") v5.8-rc1 b744b43f79cc ("kbuild: add CONFIG_LD_IS_LLD") v5.9-rc1 a6c30873ee4a ("ARM: 8989/1: use .fpu assembler directives instead of assembler arguments") v5.9-rc1 ee440336e5ef ("ARM: 8990/1: use VFP assembler mnemonics in register load/store macros") v5.9-rc1 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available") v5.10-rc1 54781938ec34 ("crypto: arm/sha256-neon - avoid ADRL pseudo instruction") v5.10-rc1 0f5e8323777b ("crypto: arm/sha512-neon - avoid ADRL pseudo instruction") v5.11-rc1 28187dc8ebd9 ("ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD")
Then 3c9f5708b7ae from the 5.10 series is applied (0b1674638a5c and 67e3f828bd4b were not necessary). 28187dc8ebd9 had previously been picked up into 5.10 automatically. There was a minor conflict in 2cbd1cc3dcd3 due to 5.10 missing 8a90a3228b6a ("arm: Unplug KVM from the build system").
b744b43f79cc and 28187dc8ebd9 are more specifically for allmodconfig support than strictly LLVM_IAS=1.
For 4.19: v4.20-rc1 d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support") v4.20-rc1 f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders") v5.1-rc1 baf2df8e15be ("ARM: 8827/1: fix argument count to match macro definition") v5.1-rc1 32fdb046ac43 ("ARM: 8828/1: uaccess: use unified assembler language syntax") v5.1-rc1 eb7ff9023e4f ("ARM: 8829/1: spinlock: use unified assembler language syntax") v5.1-rc1 a216376add73 ("ARM: 8841/1: use unified assembler in macros") v5.1-rc1 e44fc38818ed ("ARM: 8844/1: use unified assembler in assembly files") v5.2-rc1 fe09d9c641f2 ("ARM: 8852/1: uaccess: use unified assembler language syntax") v5.2-rc1 3ab2b5fdd1d8 ("ARM: mvebu: drop unnecessary label") v5.2-rc1 969ad77c14ab ("ARM: mvebu: prefix coprocessor operand with p") v5.3-rc1 3fe1ee40b2a2 ("ARM: use arch_extension directive instead of arch argument") v5.4-rc3 3aa6d4abd4eb ("crypto: arm/aes-ce - build for v8 architecture explicitly")
Then the entire 5.4 series is applied on top. 3fe1ee40b2a2 had a minor conflict due to 4.19 missing 2997520c2d4e ("ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs").
I plan to send some follow ups; I need to do another pass to find what we may need in addition when setting CONFIG_THUMB2_KERNEL=y (non-default), there are two patches working their way through the ARM maintainer's tree needed for allmodconfig (https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9061/1 and https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9062/1) and v4.19.y has one more issue I need to look into (https://github.com/ClangBuiltLinux/linux/issues/1329) that has been cleaned up by a 7 patch series that landed in v5.2-rc1, but on first glance I suspect might be an assembler bug for us to fix.
These series will be used in Android and ChromeOS. We're also ready to wire up CI coverage for LLVM_IAS=1 ARCH=arm for these branches.
You still have odd Android/ChromeOS things in these patches ("FROMLIST", Change-ID, etc.)
Please fix them up, as-is, we can't take these.
thanks,
greg k-h
On Fri, Mar 12, 2021 at 2:12 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Mar 11, 2021 at 11:32:22AM -0800, Nick Desaulniers wrote:
Dear stable kernel maintainers, Please consider merging the following patch series'. They enable clang's integrated assembler to be used to assemble ARCH=arm kernels back to linux-4.19.y. This is analogous to previous series' sent for LLVM_IAS=1 support, but focused on ARM (32b).
Below is the list of commits in each series, in the form <first tag of mainline containing sha> <sha12> <commit oneline>
For 5.10: v5.11-rc1 3c9f5708b7ae ("ARM: 9029/1: Make iwmmxt.S support Clang's integrated assembler") v5.11-rc1 0b1674638a5c ("ARM: assembler: introduce adr_l, ldr_l and str_l macros") v5.11-rc1 67e3f828bd4b ("ARM: efistub: replace adrl pseudo-op with adr_l macro invocation")
For 5.4: v5.5-rc1 b4d0c0aad57a ("crypto: arm - use Kconfig based compiler checks for crypto opcodes") v5.5-rc1 9f1984c6ae30 ("ARM: 8929/1: use APSR_nzcv instead of r15 as mrc operand") v5.5-rc1 790756c7e022 ("ARM: 8933/1: replace Sun/Solaris style flag on section directive") v5.6-rc1 42d519e3d0c0 ("kbuild: Add support for 'as-instr' to be used in Kconfig files") v5.7-rc1 7548bf8c17d8 ("crypto: arm/ghash-ce - define fpu before fpu registers are referenced") v5.8-rc1 d85d5247885e ("ARM: OMAP2+: drop unnecessary adrl") v5.8-rc1 a780e485b576 ("ARM: 8971/1: replace the sole use of a symbol with its definition") v5.8-rc1 b744b43f79cc ("kbuild: add CONFIG_LD_IS_LLD") v5.9-rc1 a6c30873ee4a ("ARM: 8989/1: use .fpu assembler directives instead of assembler arguments") v5.9-rc1 ee440336e5ef ("ARM: 8990/1: use VFP assembler mnemonics in register load/store macros") v5.9-rc1 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available") v5.10-rc1 54781938ec34 ("crypto: arm/sha256-neon - avoid ADRL pseudo instruction") v5.10-rc1 0f5e8323777b ("crypto: arm/sha512-neon - avoid ADRL pseudo instruction") v5.11-rc1 28187dc8ebd9 ("ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD")
Then 3c9f5708b7ae from the 5.10 series is applied (0b1674638a5c and 67e3f828bd4b were not necessary). 28187dc8ebd9 had previously been picked up into 5.10 automatically. There was a minor conflict in 2cbd1cc3dcd3 due to 5.10 missing 8a90a3228b6a ("arm: Unplug KVM from the build system").
b744b43f79cc and 28187dc8ebd9 are more specifically for allmodconfig support than strictly LLVM_IAS=1.
For 4.19: v4.20-rc1 d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support") v4.20-rc1 f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders") v5.1-rc1 baf2df8e15be ("ARM: 8827/1: fix argument count to match macro definition") v5.1-rc1 32fdb046ac43 ("ARM: 8828/1: uaccess: use unified assembler language syntax") v5.1-rc1 eb7ff9023e4f ("ARM: 8829/1: spinlock: use unified assembler language syntax") v5.1-rc1 a216376add73 ("ARM: 8841/1: use unified assembler in macros") v5.1-rc1 e44fc38818ed ("ARM: 8844/1: use unified assembler in assembly files") v5.2-rc1 fe09d9c641f2 ("ARM: 8852/1: uaccess: use unified assembler language syntax") v5.2-rc1 3ab2b5fdd1d8 ("ARM: mvebu: drop unnecessary label") v5.2-rc1 969ad77c14ab ("ARM: mvebu: prefix coprocessor operand with p") v5.3-rc1 3fe1ee40b2a2 ("ARM: use arch_extension directive instead of arch argument") v5.4-rc3 3aa6d4abd4eb ("crypto: arm/aes-ce - build for v8 architecture explicitly")
Then the entire 5.4 series is applied on top. 3fe1ee40b2a2 had a minor conflict due to 4.19 missing 2997520c2d4e ("ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs").
I plan to send some follow ups; I need to do another pass to find what we may need in addition when setting CONFIG_THUMB2_KERNEL=y (non-default), there are two patches working their way through the ARM maintainer's tree needed for allmodconfig (https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9061/1 and https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9062/1) and v4.19.y has one more issue I need to look into (https://github.com/ClangBuiltLinux/linux/issues/1329) that has been cleaned up by a 7 patch series that landed in v5.2-rc1, but on first glance I suspect might be an assembler bug for us to fix.
These series will be used in Android and ChromeOS. We're also ready to wire up CI coverage for LLVM_IAS=1 ARCH=arm for these branches.
You still have odd Android/ChromeOS things in these patches ("FROMLIST", Change-ID, etc.)
Please fix them up, as-is, we can't take these.
My mistake, meant to lop those last two commits off of 4.19.y, they were the ones I referred to earlier working their way through the ARM maintainers tree. Regenerated the series' (rather than edit the patch files) additionally with --base=auto. Re-attached.
On Fri, Mar 12, 2021 at 09:28:56AM -0800, Nick Desaulniers wrote:
My mistake, meant to lop those last two commits off of 4.19.y, they were the ones I referred to earlier working their way through the ARM maintainers tree. Regenerated the series' (rather than edit the patch files) additionally with --base=auto. Re-attached.
Queued up, thanks!
On Fri, Mar 12, 2021 at 11:07:39PM -0500, Sasha Levin wrote:
On Fri, Mar 12, 2021 at 09:28:56AM -0800, Nick Desaulniers wrote:
My mistake, meant to lop those last two commits off of 4.19.y, they were the ones I referred to earlier working their way through the ARM maintainers tree. Regenerated the series' (rather than edit the patch files) additionally with --base=auto. Re-attached.
Queued up, thanks!
This series seems to cause build breakages in a lot of places, so I'm going to drop the whole set of them now: https://lore.kernel.org/r/be846d89-ab5a-f02a-c05e-1cd40acc5baa@roeck-us.net and: https://lore.kernel.org/r/066efc42-0788-8668-2ff5-d431e77068b5@roeck-us.net
Nick, if you want these merged, can you fix up the errors and resend?
Perhaps you might want to run these through the tuxbuild tool before sending? You should have access to it...
thanks,
greg k-h
On Mon, Mar 15, 2021 at 10:08:49AM +0100, Greg KH wrote:
On Fri, Mar 12, 2021 at 11:07:39PM -0500, Sasha Levin wrote:
On Fri, Mar 12, 2021 at 09:28:56AM -0800, Nick Desaulniers wrote:
My mistake, meant to lop those last two commits off of 4.19.y, they were the ones I referred to earlier working their way through the ARM maintainers tree. Regenerated the series' (rather than edit the patch files) additionally with --base=auto. Re-attached.
Queued up, thanks!
This series seems to cause build breakages in a lot of places, so I'm going to drop the whole set of them now: https://lore.kernel.org/r/be846d89-ab5a-f02a-c05e-1cd40acc5baa@roeck-us.net and: https://lore.kernel.org/r/066efc42-0788-8668-2ff5-d431e77068b5@roeck-us.net
Nick, if you want these merged, can you fix up the errors and resend?
Perhaps you might want to run these through the tuxbuild tool before sending? You should have access to it...
Oops, wait, they are fine for 5.10.y, just 4.19 and 5.4 are broken, will go drop those patches only.
thanks,
greg k-h
On Mon, Mar 15, 2021 at 10:12:31AM +0100, Greg KH wrote:
On Mon, Mar 15, 2021 at 10:08:49AM +0100, Greg KH wrote:
On Fri, Mar 12, 2021 at 11:07:39PM -0500, Sasha Levin wrote:
On Fri, Mar 12, 2021 at 09:28:56AM -0800, Nick Desaulniers wrote:
My mistake, meant to lop those last two commits off of 4.19.y, they were the ones I referred to earlier working their way through the ARM maintainers tree. Regenerated the series' (rather than edit the patch files) additionally with --base=auto. Re-attached.
Queued up, thanks!
This series seems to cause build breakages in a lot of places, so I'm going to drop the whole set of them now: https://lore.kernel.org/r/be846d89-ab5a-f02a-c05e-1cd40acc5baa@roeck-us.net and: https://lore.kernel.org/r/066efc42-0788-8668-2ff5-d431e77068b5@roeck-us.net
Nick, if you want these merged, can you fix up the errors and resend?
Perhaps you might want to run these through the tuxbuild tool before sending? You should have access to it...
Oops, wait, they are fine for 5.10.y, just 4.19 and 5.4 are broken, will go drop those patches only.
Also, these are a lot of churn for 5.4 and 4.19, I'm not convinced it's really needed there. Why again is this required?
thanks,
greg k-h
On Mon, 15 Mar 2021 at 10:16, Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Mar 15, 2021 at 10:12:31AM +0100, Greg KH wrote:
On Mon, Mar 15, 2021 at 10:08:49AM +0100, Greg KH wrote:
On Fri, Mar 12, 2021 at 11:07:39PM -0500, Sasha Levin wrote:
On Fri, Mar 12, 2021 at 09:28:56AM -0800, Nick Desaulniers wrote:
My mistake, meant to lop those last two commits off of 4.19.y, they were the ones I referred to earlier working their way through the ARM maintainers tree. Regenerated the series' (rather than edit the patch files) additionally with --base=auto. Re-attached.
Queued up, thanks!
This series seems to cause build breakages in a lot of places, so I'm going to drop the whole set of them now: https://lore.kernel.org/r/be846d89-ab5a-f02a-c05e-1cd40acc5baa@roeck-us.net and: https://lore.kernel.org/r/066efc42-0788-8668-2ff5-d431e77068b5@roeck-us.net
Nick, if you want these merged, can you fix up the errors and resend?
Perhaps you might want to run these through the tuxbuild tool before sending? You should have access to it...
Oops, wait, they are fine for 5.10.y, just 4.19 and 5.4 are broken, will go drop those patches only.
Also, these are a lot of churn for 5.4 and 4.19, I'm not convinced it's really needed there. Why again is this required?
I think backporting this stuff is causing more problems than it solves. 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?)
So I really think we should apply more caution here, and have a *really* good story on why it is essential that these patches are backported. In this case, I am not convinced there is one.
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
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.
Ok, I see what went wrong. I had tested allyesconfig and allmodconfig on 5.4.y, but neither of those selects CONFIG_KVM=y for arm; axm55xx_defconfig is literally the only config (out of 109) that does.
32b ARM KVM support was ripped out in commit 541ad0150ca4 ("arm: Remove 32bit KVM host support") which landed in v5.7-rc1. So when commit 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available") was written, arch/arm/kvm/ no longer existed. If it did, then 2cbd1cc3dcd3 would have needed something like https://gist.github.com/nickdesaulniers/980e68e9c0680fff06b1b64f2b973171. And allmodconfig/allyesconfig testing wouldn't have caught this, only testing axm55xx_defconfig would have. Before KVM support was dropped, that was the only config that explicitly enabled the config that failed.
On Mon, Mar 15, 2021 at 10:53 AM Ard Biesheuvel ardb@kernel.org wrote:
On Mon, 15 Mar 2021 at 18:43, Nick Desaulniers ndesaulniers@google.com wrote:
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?
I assume we still want a fix for THUMB2, so I'll send a backport of just f77ac2e378be modified to note that there was a fixup against 2cbd1cc3dcd3, since 2cbd1cc3dcd3 is problematic for CONFIG_KVM=y on 5.4.
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?
Ah, sorry, ChromeOS and Android very much do so. (Google's production kernels as well, though I don't think they have any 32b ARM machines). Android is already building 4.19+ with LLVM_IAS=1 for ARCH=arm64,x86_64,i686. ChromeOS is doing so for 5.4+ for ARCH=arm64,x86_64 as well. I'm not sure precisely what's going on in prodkernel land, but I know they have LLVM_IAS=1 enabled for x86_64. So when Greg says this is "for no real users" I disagree. Maybe no one is using LLVM_IAS=1 for ARCH=arm at this moment, but that was the point of the backports, to enable more distros to do so.
Stable has already accepted patches to 4.19+ for these architectures where it was made explicit that this was for LLVM_IAS=1 support. https://lore.kernel.org/stable/CAKwvOdk_U6SEwOC-ykaVTMu1ZmEjWC8cCiTetvU2k2dQ... https://lore.kernel.org/stable/CAKwvOd=F_wWLxhnV3J8jx1L3SXPd8NFYyOKzAh7rL0iR... https://lore.kernel.org/stable/CAKwvOdmEcjjw78K0Avj-7s5BBXcT7ARhEMMEYqpCP-ZT... https://lore.kernel.org/stable/CAKwvOdnGDHn+Y+g5AsKvOFiuF7iVAJ8+x53SgWxH9ejq... https://lore.kernel.org/stable/CAKwvOdkK1LgLC4ChptzUTC45WvE9-Sn0OqtgF7-odNSw... https://lore.kernel.org/stable/CAKwvOd=x+fVo1_mMJUGHYXpmGf8UM5yx+uWD-Ci=y=0o... https://lore.kernel.org/stable/CAKwvOdn78WAUiRtyPxW7oEhUz8GN6MkL=Jt+n17jEQXP...
Now it's just down to ARM and THUMB2 support. Then we will be using a similar toolchain regardless of ISA. We will also then have an evergreen toolchain, rather than one that will not be receiving future updates and is unsupported (which becomes a problem when folks need new things and is a liability to be removed), and more wood behind fewer arrows so we can focus on starting on the feature requests we have piling up (like kernel GCC plugin-like features in LLVM, like a code model for the kernel, etc).
This has been communicated to Android OEMs (https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/m...) for them to help test and report issues and likely will also happen for the next release of the NDK (https://github.com/android/ndk/wiki/Changelog-r23#announcements).
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.
LTO does require LLVM_IAS=1 at the moment; there are no plans I know of yet to port LTO to ARCH=arm, but maybe if Sami is bored? :P
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.
I understand. I'm also balancing shipping patches for toolchain support out of tree, vs upstreaming. Everything so far has been upstreamed, but 32b ARM support has been...more involved. But I'm hopeful that we will be able to expand our staff soon to better improve that.
I think all of these patches would be useful to CrOS, so my plan was to send the series upstream. We can keep it downstream, where the number of supported configurations and toolchains is more limited. 4.19+ is of interest for new Android devices this year, but 5.4 in particular will live much longer, so we will have to carry the divergence for longer. I think some of the strictly UAL related changes are relatively lower risk.
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.
From: Ard Biesheuvel ardb@kernel.org
commit f77ac2e378be9dd61eb88728f0840642f045d9d1 upstream.
There are a couple of problems with the exception entry code that deals with FP exceptions (which are reported as UND exceptions) when building the kernel in Thumb2 mode: - the conditional branch to vfp_kmode_exception in vfp_support_entry() may be out of range for its target, depending on how the linker decides to arrange the sections; - when the UND exception is taken in kernel mode, the emulation handling logic is entered via the 'call_fpe' label, which means we end up using the wrong value/mask pairs to match and detect the NEON opcodes.
Since UND exceptions in kernel mode are unlikely to occur on a hot path (as opposed to the user mode version which is invoked for VFP support code and lazy restore), we can use the existing undef hook machinery for any kernel mode instruction emulation that is needed, including calling the existing vfp_kmode_exception() routine for unexpected cases. So drop the call to call_fpe, and instead, install an undef hook that will get called for NEON and VFP instructions that trigger an UND exception in kernel mode.
While at it, make sure that the PC correction is accurate for the execution mode where the exception was taken, by checking the PSR Thumb bit.
Cc: Dmitry Osipenko digetx@gmail.com Cc: Kees Cook keescook@chromium.org Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections") Signed-off-by: Ard Biesheuvel ardb@kernel.org Reviewed-by: Linus Walleij linus.walleij@linaro.org Reviewed-by: Nick Desaulniers ndesaulniers@google.com Signed-off-by: Russell King rmk+kernel@armlinux.org.uk [nd: fix conflict in arch/arm/vfp/vfphw.S due to missing commit 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available")] Signed-off-by: Nick Desaulniers ndesaulniers@google.com --- This should have been sent along with https://lore.kernel.org/stable/20210113185758.GA571703@ubuntu-m3-large-x86/ it's my fault I missed it.
arch/arm/kernel/entry-armv.S | 25 ++---------------- arch/arm/vfp/vfphw.S | 5 ---- arch/arm/vfp/vfpmodule.c | 49 ++++++++++++++++++++++++++++++++++-- 3 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index a874b753397e..b62d74a2c73a 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -252,31 +252,10 @@ __und_svc: #else svc_entry #endif - @ - @ call emulation code, which returns using r9 if it has emulated - @ the instruction, or the more conventional lr if we are to treat - @ this as a real undefined instruction - @ - @ r0 - instruction - @ -#ifndef CONFIG_THUMB2_KERNEL - ldr r0, [r4, #-4] -#else - mov r1, #2 - ldrh r0, [r4, #-2] @ Thumb instruction at LR - 2 - cmp r0, #0xe800 @ 32-bit instruction if xx >= 0 - blo __und_svc_fault - ldrh r9, [r4] @ bottom 16 bits - add r4, r4, #2 - str r4, [sp, #S_PC] - orr r0, r9, r0, lsl #16 -#endif - badr r9, __und_svc_finish - mov r2, r4 - bl call_fpe
mov r1, #4 @ PC correction to apply -__und_svc_fault: + THUMB( tst r5, #PSR_T_BIT ) @ exception taken in Thumb mode? + THUMB( movne r1, #2 ) @ if so, fix up PC correction mov r0, sp @ struct pt_regs *regs bl __und_fault
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S index b2e560290860..b530db8f2c6c 100644 --- a/arch/arm/vfp/vfphw.S +++ b/arch/arm/vfp/vfphw.S @@ -78,11 +78,6 @@ ENTRY(vfp_support_entry) DBGSTR3 "instr %08x pc %08x state %p", r0, r2, r10
- ldr r3, [sp, #S_PSR] @ Neither lazy restore nor FP exceptions - and r3, r3, #MODE_MASK @ are supported in kernel mode - teq r3, #USR_MODE - bne vfp_kmode_exception @ Returns through lr - VFPFMRX r1, FPEXC @ Is the VFP enabled? DBGSTR1 "fpexc %08x", r1 tst r1, #FPEXC_EN diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 8c9e7f9f0277..c3b6451c18bd 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -23,6 +23,7 @@ #include <asm/cputype.h> #include <asm/system_info.h> #include <asm/thread_notify.h> +#include <asm/traps.h> #include <asm/vfp.h>
#include "vfpinstr.h" @@ -642,7 +643,9 @@ static int vfp_starting_cpu(unsigned int unused) return 0; }
-void vfp_kmode_exception(void) +#ifdef CONFIG_KERNEL_MODE_NEON + +static int vfp_kmode_exception(struct pt_regs *regs, unsigned int instr) { /* * If we reach this point, a floating point exception has been raised @@ -660,9 +663,51 @@ void vfp_kmode_exception(void) pr_crit("BUG: unsupported FP instruction in kernel mode\n"); else pr_crit("BUG: FP instruction issued in kernel mode with FP unit disabled\n"); + pr_crit("FPEXC == 0x%08x\n", fmrx(FPEXC)); + return 1; }
-#ifdef CONFIG_KERNEL_MODE_NEON +static struct undef_hook vfp_kmode_exception_hook[] = {{ + .instr_mask = 0xfe000000, + .instr_val = 0xf2000000, + .cpsr_mask = MODE_MASK | PSR_T_BIT, + .cpsr_val = SVC_MODE, + .fn = vfp_kmode_exception, +}, { + .instr_mask = 0xff100000, + .instr_val = 0xf4000000, + .cpsr_mask = MODE_MASK | PSR_T_BIT, + .cpsr_val = SVC_MODE, + .fn = vfp_kmode_exception, +}, { + .instr_mask = 0xef000000, + .instr_val = 0xef000000, + .cpsr_mask = MODE_MASK | PSR_T_BIT, + .cpsr_val = SVC_MODE | PSR_T_BIT, + .fn = vfp_kmode_exception, +}, { + .instr_mask = 0xff100000, + .instr_val = 0xf9000000, + .cpsr_mask = MODE_MASK | PSR_T_BIT, + .cpsr_val = SVC_MODE | PSR_T_BIT, + .fn = vfp_kmode_exception, +}, { + .instr_mask = 0x0c000e00, + .instr_val = 0x0c000a00, + .cpsr_mask = MODE_MASK, + .cpsr_val = SVC_MODE, + .fn = vfp_kmode_exception, +}}; + +static int __init vfp_kmode_exception_hook_init(void) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(vfp_kmode_exception_hook); i++) + register_undef_hook(&vfp_kmode_exception_hook[i]); + return 0; +} +core_initcall(vfp_kmode_exception_hook_init);
/* * Kernel-side NEON support functions
On Tue, 16 Mar 2021 at 00:19, Nick Desaulniers ndesaulniers@google.com wrote:
From: Ard Biesheuvel ardb@kernel.org
commit f77ac2e378be9dd61eb88728f0840642f045d9d1 upstream.
There are a couple of problems with the exception entry code that deals with FP exceptions (which are reported as UND exceptions) when building the kernel in Thumb2 mode:
- the conditional branch to vfp_kmode_exception in vfp_support_entry() may be out of range for its target, depending on how the linker decides to arrange the sections;
- when the UND exception is taken in kernel mode, the emulation handling logic is entered via the 'call_fpe' label, which means we end up using the wrong value/mask pairs to match and detect the NEON opcodes.
Since UND exceptions in kernel mode are unlikely to occur on a hot path (as opposed to the user mode version which is invoked for VFP support code and lazy restore), we can use the existing undef hook machinery for any kernel mode instruction emulation that is needed, including calling the existing vfp_kmode_exception() routine for unexpected cases. So drop the call to call_fpe, and instead, install an undef hook that will get called for NEON and VFP instructions that trigger an UND exception in kernel mode.
While at it, make sure that the PC correction is accurate for the execution mode where the exception was taken, by checking the PSR Thumb bit.
Cc: Dmitry Osipenko digetx@gmail.com Cc: Kees Cook keescook@chromium.org Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections") Signed-off-by: Ard Biesheuvel ardb@kernel.org Reviewed-by: Linus Walleij linus.walleij@linaro.org Reviewed-by: Nick Desaulniers ndesaulniers@google.com Signed-off-by: Russell King rmk+kernel@armlinux.org.uk [nd: fix conflict in arch/arm/vfp/vfphw.S due to missing commit 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available")] Signed-off-by: Nick Desaulniers ndesaulniers@google.com
This should have been sent along with https://lore.kernel.org/stable/20210113185758.GA571703@ubuntu-m3-large-x86/ it's my fault I missed it.
This breaks the boot on non-VFP capable hardware unless commit 3cce9d44321e460e7c88
ARM: 9044/1: vfp: use undef hook for VFP support detection
is applied as well, so please treat these as a pair for the purpose of backporting.
arch/arm/kernel/entry-armv.S | 25 ++---------------- arch/arm/vfp/vfphw.S | 5 ---- arch/arm/vfp/vfpmodule.c | 49 ++++++++++++++++++++++++++++++++++-- 3 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index a874b753397e..b62d74a2c73a 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -252,31 +252,10 @@ __und_svc: #else svc_entry #endif
@@ call emulation code, which returns using r9 if it has emulated@ the instruction, or the more conventional lr if we are to treat@ this as a real undefined instruction@@ r0 - instruction@-#ifndef CONFIG_THUMB2_KERNEL
ldr r0, [r4, #-4]-#else
mov r1, #2ldrh r0, [r4, #-2] @ Thumb instruction at LR - 2cmp r0, #0xe800 @ 32-bit instruction if xx >= 0blo __und_svc_faultldrh r9, [r4] @ bottom 16 bitsadd r4, r4, #2str r4, [sp, #S_PC]orr r0, r9, r0, lsl #16-#endif
badr r9, __und_svc_finishmov r2, r4bl call_fpe mov r1, #4 @ PC correction to apply-__und_svc_fault:
- THUMB( tst r5, #PSR_T_BIT ) @ exception taken in Thumb mode?
- THUMB( movne r1, #2 ) @ if so, fix up PC correction mov r0, sp @ struct pt_regs *regs bl __und_fault
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S index b2e560290860..b530db8f2c6c 100644 --- a/arch/arm/vfp/vfphw.S +++ b/arch/arm/vfp/vfphw.S @@ -78,11 +78,6 @@ ENTRY(vfp_support_entry) DBGSTR3 "instr %08x pc %08x state %p", r0, r2, r10
ldr r3, [sp, #S_PSR] @ Neither lazy restore nor FP exceptionsand r3, r3, #MODE_MASK @ are supported in kernel modeteq r3, #USR_MODEbne vfp_kmode_exception @ Returns through lrVFPFMRX r1, FPEXC @ Is the VFP enabled? DBGSTR1 "fpexc %08x", r1 tst r1, #FPEXC_ENdiff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 8c9e7f9f0277..c3b6451c18bd 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -23,6 +23,7 @@ #include <asm/cputype.h> #include <asm/system_info.h> #include <asm/thread_notify.h> +#include <asm/traps.h> #include <asm/vfp.h>
#include "vfpinstr.h" @@ -642,7 +643,9 @@ static int vfp_starting_cpu(unsigned int unused) return 0; }
-void vfp_kmode_exception(void) +#ifdef CONFIG_KERNEL_MODE_NEON
+static int vfp_kmode_exception(struct pt_regs *regs, unsigned int instr) { /* * If we reach this point, a floating point exception has been raised @@ -660,9 +663,51 @@ void vfp_kmode_exception(void) pr_crit("BUG: unsupported FP instruction in kernel mode\n"); else pr_crit("BUG: FP instruction issued in kernel mode with FP unit disabled\n");
pr_crit("FPEXC == 0x%08x\n", fmrx(FPEXC));return 1;}
-#ifdef CONFIG_KERNEL_MODE_NEON +static struct undef_hook vfp_kmode_exception_hook[] = {{
.instr_mask = 0xfe000000,.instr_val = 0xf2000000,.cpsr_mask = MODE_MASK | PSR_T_BIT,.cpsr_val = SVC_MODE,.fn = vfp_kmode_exception,+}, {
.instr_mask = 0xff100000,.instr_val = 0xf4000000,.cpsr_mask = MODE_MASK | PSR_T_BIT,.cpsr_val = SVC_MODE,.fn = vfp_kmode_exception,+}, {
.instr_mask = 0xef000000,.instr_val = 0xef000000,.cpsr_mask = MODE_MASK | PSR_T_BIT,.cpsr_val = SVC_MODE | PSR_T_BIT,.fn = vfp_kmode_exception,+}, {
.instr_mask = 0xff100000,.instr_val = 0xf9000000,.cpsr_mask = MODE_MASK | PSR_T_BIT,.cpsr_val = SVC_MODE | PSR_T_BIT,.fn = vfp_kmode_exception,+}, {
.instr_mask = 0x0c000e00,.instr_val = 0x0c000a00,.cpsr_mask = MODE_MASK,.cpsr_val = SVC_MODE,.fn = vfp_kmode_exception,+}};
+static int __init vfp_kmode_exception_hook_init(void) +{
int i;for (i = 0; i < ARRAY_SIZE(vfp_kmode_exception_hook); i++)register_undef_hook(&vfp_kmode_exception_hook[i]);return 0;+} +core_initcall(vfp_kmode_exception_hook_init);
/*
- Kernel-side NEON support functions
-- 2.31.0.rc2.261.g7f71774620-goog
From: Ard Biesheuvel ardb@kernel.org
commit 3cce9d44321e460e7c88cdec4e4537a6e9ad7c0d upstream.
Commit f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode") failed to take into account that there is in fact a case where we relied on this code path: during boot, the VFP detection code issues a read of FPSID, which will trigger an undef exception on cores that lack VFP support.
So let's reinstate this logic using an undef hook which is registered only for the duration of the initcall to vpf_init(), and which sets VFP_arch to a non-zero value - as before - if no VFP support is present.
Fixes: f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND ...") Reported-by: "kernelci.org bot" bot@kernelci.org Signed-off-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Russell King rmk+kernel@armlinux.org.uk Signed-off-by: Nick Desaulniers ndesaulniers@google.com --- This is meant to be applied on top of https://lore.kernel.org/stable/20210315231952.1482097-1-ndesaulniers@google..... If it's preferrable to send an .mbox file or a series with cover letter, I'm happy to resend it as such, just let me know.
arch/arm/vfp/entry.S | 17 ----------------- arch/arm/vfp/vfpmodule.c | 25 ++++++++++++++++++++----- 2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S index 0186cf9da890..27b0a1f27fbd 100644 --- a/arch/arm/vfp/entry.S +++ b/arch/arm/vfp/entry.S @@ -37,20 +37,3 @@ ENDPROC(vfp_null_entry) .align 2 .LCvfp: .word vfp_vector - -@ This code is called if the VFP does not exist. It needs to flag the -@ failure to the VFP initialisation code. - - __INIT -ENTRY(vfp_testing_entry) - dec_preempt_count_ti r10, r4 - ldr r0, VFP_arch_address - str r0, [r0] @ set to non-zero value - ret r9 @ we have handled the fault -ENDPROC(vfp_testing_entry) - - .align 2 -VFP_arch_address: - .word VFP_arch - - __FINIT diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index c3b6451c18bd..2cb355c1b5b7 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -32,7 +32,6 @@ /* * Our undef handlers (in entry.S) */ -asmlinkage void vfp_testing_entry(void); asmlinkage void vfp_support_entry(void); asmlinkage void vfp_null_entry(void);
@@ -43,7 +42,7 @@ asmlinkage void (*vfp_vector)(void) = vfp_null_entry; * Used in startup: set to non-zero if VFP checks fail * After startup, holds VFP architecture */ -unsigned int VFP_arch; +static unsigned int __initdata VFP_arch;
/* * The pointer to the vfpstate structure of the thread which currently @@ -437,7 +436,7 @@ static void vfp_enable(void *unused) * present on all CPUs within a SMP complex. Needs to be called prior to * vfp_init(). */ -void vfp_disable(void) +void __init vfp_disable(void) { if (VFP_arch) { pr_debug("%s: should be called prior to vfp_init\n", __func__); @@ -707,7 +706,7 @@ static int __init vfp_kmode_exception_hook_init(void) register_undef_hook(&vfp_kmode_exception_hook[i]); return 0; } -core_initcall(vfp_kmode_exception_hook_init); +subsys_initcall(vfp_kmode_exception_hook_init);
/* * Kernel-side NEON support functions @@ -753,6 +752,21 @@ EXPORT_SYMBOL(kernel_neon_end);
#endif /* CONFIG_KERNEL_MODE_NEON */
+static int __init vfp_detect(struct pt_regs *regs, unsigned int instr) +{ + VFP_arch = UINT_MAX; /* mark as not present */ + regs->ARM_pc += 4; + return 0; +} + +static struct undef_hook vfp_detect_hook __initdata = { + .instr_mask = 0x0c000e00, + .instr_val = 0x0c000a00, + .cpsr_mask = MODE_MASK, + .cpsr_val = SVC_MODE, + .fn = vfp_detect, +}; + /* * VFP support code initialisation. */ @@ -773,10 +787,11 @@ static int __init vfp_init(void) * The handler is already setup to just log calls, so * we just need to read the VFPSID register. */ - vfp_vector = vfp_testing_entry; + register_undef_hook(&vfp_detect_hook); barrier(); vfpsid = fmrx(FPSID); barrier(); + unregister_undef_hook(&vfp_detect_hook); vfp_vector = vfp_null_entry;
pr_info("VFP support v0.3: ");
On Tue, Mar 16, 2021 at 09:59:18AM -0700, Nick Desaulniers wrote:
From: Ard Biesheuvel ardb@kernel.org
commit 3cce9d44321e460e7c88cdec4e4537a6e9ad7c0d upstream.
Commit f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode") failed to take into account that there is in fact a case where we relied on this code path: during boot, the VFP detection code issues a read of FPSID, which will trigger an undef exception on cores that lack VFP support.
So let's reinstate this logic using an undef hook which is registered only for the duration of the initcall to vpf_init(), and which sets VFP_arch to a non-zero value - as before - if no VFP support is present.
Fixes: f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND ...") Reported-by: "kernelci.org bot" bot@kernelci.org Signed-off-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Russell King rmk+kernel@armlinux.org.uk Signed-off-by: Nick Desaulniers ndesaulniers@google.com
This is meant to be applied on top of https://lore.kernel.org/stable/20210315231952.1482097-1-ndesaulniers@google..... If it's preferrable to send an .mbox file or a series with cover letter, I'm happy to resend it as such, just let me know.
Please resend it that way, makes it easier to figure out what is going on here...
thanks,
greg k-h
On Fri, Mar 19, 2021 at 3:06 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Mar 16, 2021 at 09:59:18AM -0700, Nick Desaulniers wrote:
If it's preferrable to send an .mbox file or a series with cover letter, I'm happy to resend it as such, just let me know.
Please resend it that way, makes it easier to figure out what is going on here...
Dear stable kernel maintainers, Please consider applying the following mbox file to linux-5.4.y. It contains 2 cherry-picks of `Fixes:` for a patch in 5.4.
Ard reported linux-5.4.y with CONFIG_THUMB2_KERNEL=y was broken without these in https://lore.kernel.org/stable/CAMj1kXGLrVXZPAoxTtMueB9toeoktuKza-mRpd4vZ0SL....
The mbox contains: commit f77ac2e378be ("ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode") commit 3cce9d44321e ("ARM: 9044/1: vfp: use undef hook for VFP support detection")
They first landed in v5.11-rc1. The first is a fixup for: commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
which exists in 5.4.90 as 87ea51c90280.
The first has a conflict in arch/arm/vfp/vfphw.S due to missing commit 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available")] in 5.4. 2cbd1cc3dcd3 causes breakage in ARCH=axm55xx_defconfig previously reported: https://lore.kernel.org/stable/be846d89-ab5a-f02a-c05e-1cd40acc5baa@roeck-us... and will need to be reworked if we ever do backport it.
On Fri, Mar 19, 2021 at 01:14:12PM -0700, Nick Desaulniers wrote:
On Fri, Mar 19, 2021 at 3:06 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Mar 16, 2021 at 09:59:18AM -0700, Nick Desaulniers wrote:
If it's preferrable to send an .mbox file or a series with cover letter, I'm happy to resend it as such, just let me know.
Please resend it that way, makes it easier to figure out what is going on here...
Dear stable kernel maintainers, Please consider applying the following mbox file to linux-5.4.y. It contains 2 cherry-picks of `Fixes:` for a patch in 5.4.
Ard reported linux-5.4.y with CONFIG_THUMB2_KERNEL=y was broken without these in https://lore.kernel.org/stable/CAMj1kXGLrVXZPAoxTtMueB9toeoktuKza-mRpd4vZ0SL....
The mbox contains: commit f77ac2e378be ("ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode") commit 3cce9d44321e ("ARM: 9044/1: vfp: use undef hook for VFP support detection")
They first landed in v5.11-rc1. The first is a fixup for: commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections")
which exists in 5.4.90 as 87ea51c90280.
The first has a conflict in arch/arm/vfp/vfphw.S due to missing commit 2cbd1cc3dcd3 ("ARM: 8991/1: use VFP assembler mnemonics if available")] in 5.4. 2cbd1cc3dcd3 causes breakage in ARCH=axm55xx_defconfig previously reported: https://lore.kernel.org/stable/be846d89-ab5a-f02a-c05e-1cd40acc5baa@roeck-us... and will need to be reworked if we ever do backport it.
Now queued up, thanks.
greg k-h
On Mon, Mar 15, 2021 at 03:58:07PM -0700, Nick Desaulniers wrote:
On Mon, Mar 15, 2021 at 10:53 AM Ard Biesheuvel ardb@kernel.org wrote:
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?
Ah, sorry, ChromeOS and Android very much do so. (Google's production kernels as well, though I don't think they have any 32b ARM machines). Android is already building 4.19+ with LLVM_IAS=1 for ARCH=arm64,x86_64,i686. ChromeOS is doing so for 5.4+ for ARCH=arm64,x86_64 as well. I'm not sure precisely what's going on in prodkernel land, but I know they have LLVM_IAS=1 enabled for x86_64. So when Greg says this is "for no real users" I disagree. Maybe no one is using LLVM_IAS=1 for ARCH=arm at this moment, but that was the point of the backports, to enable more distros to do so.
You can't both stay on a "stable" kernel because it's "stable", but then expect a flow of new features. The users which you've mentioned should be migrating to newer kernels instead of attempting to backport features they care about to stable kernels.
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
On Mon, Mar 15, 2021 at 08:06:29PM +0100, Greg KH wrote:
On Mon, Mar 15, 2021 at 10:43:26AM -0700, Nick Desaulniers wrote:
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?
I actually run something like that often, there are tons of patches with Fixes: that points to commits in the stable tree, but quite a few need a less-than-trivial backport that no one did.
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.
I run it on a weekly basis for *new* commits.
linux-stable-mirror@lists.linaro.org
-
Ard Biesheuvel -
Greg KH -
Nick Desaulniers -
Sasha Levin