| Message ID | 20210316165918.1794549-1-ndesaulniers@google.com |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
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.com/. > 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-mRpd4vZ0SLN6bSSQ@mail.gmail.com/. 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.net/ and will need to be reworked if we ever do backport it. -- Thanks, ~Nick Desaulniers
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-mRpd4vZ0SLN6bSSQ@mail.gmail.com/. > > 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.net/ > and will need to be reworked if we ever do backport it. Now queued up, thanks. greg k-h
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: ");