#
fd7c3c37 |
| 19-Oct-2023 |
Mark-PK Tsai <mark-pk.tsai@mediatek.com> |
ARM: 9327/1: vfp: Add missing VFP instructions to neon_support_hook
Add the missing "Unconditional Advanced SIMD and floating-point instructions" in [1] to the VFP undef hook.
This commit addresses
ARM: 9327/1: vfp: Add missing VFP instructions to neon_support_hook
Add the missing "Unconditional Advanced SIMD and floating-point instructions" in [1] to the VFP undef hook.
This commit addresses the issue reported in [2], where executing the vudot instruction on a platform with FEAT_DotProd support resulted in an undefined instruction error.
Link: https://developer.arm.com/documentation/ddi0597/2023-06/?lang=en [1] Link: https://lore.kernel.org/lkml/20230920083907.30479-1-mark-pk.tsai@mediatek.com/ [2]
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com> Tested-by: Xuewen Yan <xuewen.yan@unisoc.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
2332c615 |
| 02-Jun-2023 |
Arnd Bergmann <arnd@arndb.de> |
ARM: 9312/1: vfp: include asm/neon.h in vfpmodule.c
Two functions defined here need the declaration in a header to avoid W=1 warnings:
arch/arm/vfp/vfpmodule.c:735:6: error: no previous prototype f
ARM: 9312/1: vfp: include asm/neon.h in vfpmodule.c
Two functions defined here need the declaration in a header to avoid W=1 warnings:
arch/arm/vfp/vfpmodule.c:735:6: error: no previous prototype for 'kernel_neon_begin' [-Werror=missing-prototypes] arch/arm/vfp/vfpmodule.c:768:6: error: no previous prototype for 'kernel_neon_end' [-Werror=missing-prototypes]
Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
cdd87465 |
| 18-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: vfp: Use undef hook for handling VFP exceptions
Now that the VFP support code has been reimplemented as a C function that takes a struct pt_regs pointer and an opcode, we can use the existing u
ARM: vfp: Use undef hook for handling VFP exceptions
Now that the VFP support code has been reimplemented as a C function that takes a struct pt_regs pointer and an opcode, we can use the existing undef_hook framework to deal with undef exceptions triggered by VFP instructions instead of having special handling in assembler.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
4708fb04 |
| 15-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: vfp: Reimplement VFP exception entry in C code
En/disabling softirqs from asm code turned out to be trickier than expected, so vfp_support_entry now returns by tail calling __local_enable_bh_ip
ARM: vfp: Reimplement VFP exception entry in C code
En/disabling softirqs from asm code turned out to be trickier than expected, so vfp_support_entry now returns by tail calling __local_enable_bh_ip() and passing the same arguments that a C call to local_bh_enable() would pass. However, this is slightly hacky, as we don't want to carry our own implementation of local_bh_enable().
So let's bite the bullet, and get rid of the asm logic in vfp_support_entry that reasons about whether or not to save and/or reload the VFP state, and about whether or not an FP exception is pending, and only keep the VFP loading logic as a function that is callable from C.
Replicate the removed logic in vfp_entry(), and use the exact same reasoning as in the asm code. To emphasize the correspondence, retain some of the asm comments in the C version as well.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
show more ...
|
#
4a0548c6 |
| 20-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: vfp: Remove workaround for Feroceon CPUs
Feroceon CPUs have a non-standard implementation of VFP which reports synchronous VFP exceptions using the async VFP flag. This requires a workaround wh
ARM: vfp: Remove workaround for Feroceon CPUs
Feroceon CPUs have a non-standard implementation of VFP which reports synchronous VFP exceptions using the async VFP flag. This requires a workaround which is difficult to reconcile with other implementations, making it tricky to support both versions in a single image.
Since this is a v5 CPU, it is not supported by armhf and so the likelihood that anybody is using this with recent distros/kernels and rely on the VFP at the same time is extremely low. So let's just disable VFP support on these cores, so we can remove the workaround.
This will help future development to support v5 and v6 CPUs with a single kernel image.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
87691776 |
| 18-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: vfp: Record VFP bounces as perf emulation faults
VFP 'bouncing' occurs when the VFP unit cannot complete the execution of a VFP instruction, either because it is not implemented at all, or beca
ARM: vfp: Record VFP bounces as perf emulation faults
VFP 'bouncing' occurs when the VFP unit cannot complete the execution of a VFP instruction, either because it is not implemented at all, or because the values of the arguments are out of range for the hardware implementation, and the software needs to step in to complete the operation.
To give some insight in how much certain programs rely on this bouncing, record the emulation of a VFP instruction in perf's emulation-faults counter.
This can be used like so
perf stat -e emulation-faults ./testfloat -all2
and the output will be something like
Performance counter stats for './testfloat -all2':
259,277 emulation-faults:u
6.846432176 seconds time elapsed
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
c76c6c4e |
| 12-Apr-2023 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9294/2: vfp: Fix broken softirq handling with instrumentation enabled
Commit 62b95a7b44d1 ("ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled") replaced the en/disable preempti
ARM: 9294/2: vfp: Fix broken softirq handling with instrumentation enabled
Commit 62b95a7b44d1 ("ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled") replaced the en/disable preemption calls inside the VFP state handling code with en/disabling of soft IRQs, which is necessary to allow kernel use of the VFP/SIMD unit when handling a soft IRQ.
Unfortunately, when lockdep is enabled (or other instrumentation that enables TRACE_IRQFLAGS), the disable path implemented in asm fails to perform the lockdep and RCU related bookkeeping, resulting in spurious warnings and other badness.
Set let's rework the VFP entry code a little bit so we can make the local_bh_disable() call from C, with all the instrumentations that happen to have been configured. Calling local_bh_enable() can be done from asm, as it is a simple wrapper around __local_bh_enable_ip(), which is always a callable function.
Link: https://lore.kernel.org/all/ZBBYCSZUJOWBg1s8@localhost.localdomain/
Fixes: 62b95a7b44d1 ("ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
c79f8163 |
| 22-Dec-2022 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9283/1: permit non-nested kernel mode NEON in softirq context
We currently only permit kernel mode NEON in process context, to avoid the need to preserve/restore the NEON register file when tak
ARM: 9283/1: permit non-nested kernel mode NEON in softirq context
We currently only permit kernel mode NEON in process context, to avoid the need to preserve/restore the NEON register file when taking an exception while running in the kernel.
Like we did on arm64, we can relax this restriction substantially, by permitting kernel mode NEON from softirq context, while ensuring that softirq processing is disabled when the NEON is being used in task context. This guarantees that only NEON context belonging to user space needs to be preserved and restored, which is already taken care of.
This is especially relevant for network encryption, where incoming frames are typically handled in softirq context, and deferring software decryption to a kernel thread or falling back to C code are both undesirable from a performance PoV.
Tested-by: Martin Willi <martin@strongswan.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
62b95a7b |
| 22-Dec-2022 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled
In a subsequent patch, we will relax the kernel mode NEON policy, and permit kernel mode NEON to be used not only from task context
ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled
In a subsequent patch, we will relax the kernel mode NEON policy, and permit kernel mode NEON to be used not only from task context, as is permitted today, but also from softirq context.
Given that softirqs may trigger over the back of any IRQ unless they are explicitly disabled, we need to address the resulting races in the VFP state handling, by disabling softirq processing in two distinct but related cases: - kernel mode NEON will leave the FPU disabled after it completes, so any kernel code sequence that enables the FPU and subsequently accesses its registers needs to disable softirqs until it completes; - kernel_neon_begin() will preserve the userland VFP state in memory, and if it interrupts the ordinary VFP state preserve sequence, the latter will resume execution with the VFP registers corrupted, and happily continue saving them to memory.
Given that disabling softirqs also disables preemption, we can replace the existing preempt_disable/enable occurrences in the VFP state handling asm code with new macros that dis/enable softirqs instead. In the VFP state handling C code, add local_bh_disable/enable() calls in those places where the VFP state is preserved.
One thing to keep in mind is that, once we allow NEON use in softirq context, the result of any such interruption is that the FPEXC_EN bit in the FPEXC register will be cleared, and vfp_current_hw_state[cpu] will be NULL. This means that any sequence that [conditionally] clears FPEXC_EN and/or sets vfp_current_hw_state[cpu] to NULL does not need to run with softirqs disabled, as the result will be the same. Furthermore, the handling of THREAD_NOTIFY_SWITCH is guaranteed to run with IRQs disabled, and so it does not need protection from softirq interruptions either.
Tested-by: Martin Willi <martin@strongswan.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
956ca3a4 |
| 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9272/1: vfp: Add hwcap for FEAT_AA32I8MM
Int8 matrix multiplication (FEAT_AA32I8MM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.I8MM identification register.
Th
ARM: 9272/1: vfp: Add hwcap for FEAT_AA32I8MM
Int8 matrix multiplication (FEAT_AA32I8MM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.I8MM identification register.
This feature denotes the presence of VSMMLA, VSUDOT, VUMMLA, VUSMMLA and VUSDOT instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
23b6d4ad |
| 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9271/1: vfp: Add hwcap for FEAT_AA32BF16
Advanced SIMD BFloat16 (FEAT_AA32BF16) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.BF16 identification register.
This f
ARM: 9271/1: vfp: Add hwcap for FEAT_AA32BF16
Advanced SIMD BFloat16 (FEAT_AA32BF16) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.BF16 identification register.
This feature denotes the presence of VCVT, VCVTB, VCVTT, VDOT, VFMAB, VFMAT and VMMLA instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
ce483549 |
| 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9270/1: vfp: Add hwcap for FEAT_FHM
Floating-point half-precision multiplication (FHM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.FHM identification register.
ARM: 9270/1: vfp: Add hwcap for FEAT_FHM
Floating-point half-precision multiplication (FHM) is a feature present in AArch32 state for Armv8 and is represented by ISAR6.FHM identification register.
This feature denotes the presence of VFMAL and VMFSL instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
62ea0d87 |
| 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9269/1: vfp: Add hwcap for FEAT_DotProd
Advanced Dot product is a feature present in AArch32 state for Armv8 and is represented by ISAR6 identification register.
This feature denotes the prese
ARM: 9269/1: vfp: Add hwcap for FEAT_DotProd
Advanced Dot product is a feature present in AArch32 state for Armv8 and is represented by ISAR6 identification register.
This feature denotes the presence of UDOT and SDOT instructions and hence adding a hwcap will enable the userspace to check it before trying to use those instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
c00a19c8 |
| 17-Nov-2022 |
Amit Daniel Kachhap <amit.kachhap@arm.com> |
ARM: 9268/1: vfp: Add hwcap FPHP and ASIMDHP for FEAT_FP16
Floating point half-precision (FPHP) and Advanced SIMD half-precision (ASIMDHP) are VFP features (FEAT_FP16) represented by MVFR1 identific
ARM: 9268/1: vfp: Add hwcap FPHP and ASIMDHP for FEAT_FP16
Floating point half-precision (FPHP) and Advanced SIMD half-precision (ASIMDHP) are VFP features (FEAT_FP16) represented by MVFR1 identification register. These capabilities can optionally exist with VFPv3 and mandatory with VFPv4. Both these new features exist for Armv8 architecture in AArch32 state.
These hwcaps may be useful for the userspace to add conditional check before trying to use FEAT_FP16 feature specific instructions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
show more ...
|
#
3cce9d44 |
| 19-Dec-2020 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9044/1: vfp: use undef hook for VFP support detection
Commit f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode") failed to take into account that
ARM: 9044/1: vfp: use undef hook for VFP support detection
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>
show more ...
|
#
f77ac2e3 |
| 19-Nov-2020 |
Ard Biesheuvel <ardb@kernel.org> |
ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode
There are a couple of problems with the exception entry code that deals with FP exceptions (which are reported as UND ex
ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode
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>
show more ...
|
#
d2912cb1 |
| 04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
5df7a99b |
| 08-Nov-2018 |
Julien Thierry <julien.thierry@arm.com> |
ARM: 8810/1: vfp: Fix wrong assignement to ufp_exc
In vfp_preserve_user_clear_hwstate, ufp_exc->fpinst2 gets assigned to itself. It should actually be hwstate->fpinst2 that gets assigned to the ufp_
ARM: 8810/1: vfp: Fix wrong assignement to ufp_exc
In vfp_preserve_user_clear_hwstate, ufp_exc->fpinst2 gets assigned to itself. It should actually be hwstate->fpinst2 that gets assigned to the ufp_exc field.
Fixes commit 3aa2df6ec2ca6bc143a65351cca4266d03a8bc41 ("ARM: 8791/1: vfp: use __copy_to_user() when saving VFP state").
Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Julien Thierry <julien.thierry@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
show more ...
|
#
3aa2df6e |
| 11-Sep-2018 |
Julien Thierry <julien.thierry@arm.com> |
ARM: 8791/1: vfp: use __copy_to_user() when saving VFP state
Use __copy_to_user() rather than __put_user_error() for individual members when saving VFP state. This has the benefit of disabling/enabl
ARM: 8791/1: vfp: use __copy_to_user() when saving VFP state
Use __copy_to_user() rather than __put_user_error() for individual members when saving VFP state. This has the benefit of disabling/enabling PAN once per copied struct intead of once per write.
Signed-off-by: Julien Thierry <julien.thierry@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
show more ...
|
#
b0594548 |
| 16-Apr-2018 |
Eric W. Biederman <ebiederm@xmission.com> |
signal/arm: Use send_sig_fault where appropriate
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
#
42019fc5 |
| 09-Jul-2018 |
Russell King <rmk+kernel@armlinux.org.uk> |
ARM: vfp: use __copy_from_user() when restoring VFP state
__get_user_error() is used as a fast accessor to make copying structure members in the signal handling path as efficient as possible. Howev
ARM: vfp: use __copy_from_user() when restoring VFP state
__get_user_error() is used as a fast accessor to make copying structure members in the signal handling path as efficient as possible. However, with software PAN and the recent Spectre variant 1, the efficiency is reduced as these are no longer fast accessors.
In the case of software PAN, it has to switch the domain register around each access, and with Spectre variant 1, it would have to repeat the access_ok() check for each access.
Use __copy_from_user() rather than __get_user_err() for individual members when restoring VFP state.
Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
show more ...
|
#
92d44a42 |
| 12-Apr-2018 |
Russell King <rmk+kernel@armlinux.org.uk> |
ARM: fix kill( ,SIGFPE) breakage
Commit 7771c6645700 ("signal/arm: Document conflicts with SI_USER and SIGFPE") broke the siginfo structure for userspace triggered signals, causing the strace testsu
ARM: fix kill( ,SIGFPE) breakage
Commit 7771c6645700 ("signal/arm: Document conflicts with SI_USER and SIGFPE") broke the siginfo structure for userspace triggered signals, causing the strace testsuite to regress. Fix this by eliminating the FPE_FIXME definition (which is at the root of the breakage) and use FPE_FLTINV instead for the case where the hardware appears to be reporting nonsense.
Fixes: 7771c6645700 ("signal/arm: Document conflicts with SI_USER and SIGFPE") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
show more ...
|
#
3eb0f519 |
| 17-Apr-2018 |
Eric W. Biederman <ebiederm@xmission.com> |
signal: Ensure every siginfo we send has all bits initialized
Call clear_siginfo to ensure every stack allocated siginfo is properly initialized before being passed to the signal sending functions.
signal: Ensure every siginfo we send has all bits initialized
Call clear_siginfo to ensure every stack allocated siginfo is properly initialized before being passed to the signal sending functions.
Note: It is not safe to depend on C initializers to initialize struct siginfo on the stack because C is allowed to skip holes when initializing a structure.
The initialization of struct siginfo in tracehook_report_syscall_exit was moved from the helper user_single_step_siginfo into tracehook_report_syscall_exit itself, to make it clear that the local variable siginfo gets fully initialized.
In a few cases the scope of struct siginfo has been reduced to make it clear that siginfo siginfo is not used on other paths in the function in which it is declared.
Instances of using memset to initialize siginfo have been replaced with calls clear_siginfo for clarity.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
show more ...
|
#
1328f020 |
| 22-Jan-2018 |
Fabio Estevam <festevam@gmail.com> |
ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu") fixed the cpu dying notifier by clearing vfp_current_h
ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu") fixed the cpu dying notifier by clearing vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine") incorrectly used the original vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to clearing vfp_current_hw_state[].
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine") Cc: linux-stable <stable@vger.kernel.org> Reported-by: Kohji Okuno <okuno.kohji@jp.panasonic.com> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
show more ...
|
#
7771c664 |
| 17-Aug-2017 |
Eric W. Biederman <ebiederm@xmission.com> |
signal/arm: Document conflicts with SI_USER and SIGFPE
Setting si_code to 0 results in a userspace seeing an si_code of 0. This is the same si_code as SI_USER. Posix and common sense requires that
signal/arm: Document conflicts with SI_USER and SIGFPE
Setting si_code to 0 results in a userspace seeing an si_code of 0. This is the same si_code as SI_USER. Posix and common sense requires that SI_USER not be a signal specific si_code. As such this use of 0 for the si_code is a pretty horribly broken ABI.
Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a value of __SI_KILL and now sees a value of SIL_KILL with the result that uid and pid fields are copied and which might copying the si_addr field by accident but certainly not by design. Making this a very flakey implementation.
Utilizing FPE_FIXME, siginfo_layout will now return SIL_FAULT and the appropriate fields will be reliably copied.
Possible ABI fixes includee: - Send the signal without siginfo - Don't generate a signal - Possibly assign and use an appropriate si_code - Don't handle cases which can't happen
Cc: Russell King <rmk@flint.arm.linux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Ref: 451436b7bbb2 ("[ARM] Add support code for ARM hardware vector floating point") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
show more ...
|