#
8c46def4 |
| 06-Mar-2024 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Add FPMR signal handling
Expose FPMR in the signal context on systems where it is supported. The kernel validates the exact size of the FPSIMD registers so we can't readily add it to f
arm64/signal: Add FPMR signal handling
Expose FPMR in the signal context on systems where it is supported. The kernel validates the exact size of the FPSIMD registers so we can't readily add it to fpsimd_context without disruption.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240306-arm64-2023-dpisa-v5-4-c568edc8ed7f@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
997d79eb |
| 06-Feb-2024 |
Mark Rutland <mark.rutland@arm.com> |
arm64: Move do_notify_resume() to entry-common.c
Currently do_notify_resume() lives in arch/arm64/kernel/signal.c, but it would make more sense for it to live in entry-common.c as it handles more th
arm64: Move do_notify_resume() to entry-common.c
Currently do_notify_resume() lives in arch/arm64/kernel/signal.c, but it would make more sense for it to live in entry-common.c as it handles more than signals, and is coupled with the rest of the return-to-userspace sequence (e.g. with unusual DAIF masking that matches the exception return requirements).
Move do_notify_resume() to entry-common.c.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240206123848.1696480-3-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Itaru Kitayama <itaru.kitayama@linux.dev>
show more ...
|
#
270de609 |
| 06-Feb-2024 |
Mark Rutland <mark.rutland@arm.com> |
arm64: Simplify do_notify_resume() DAIF masking
In do_notify_resume, we handle _TIF_NEED_RESCHED differently from all other flags, leaving IRQ+FIQ masked when calling into schedule(). This masking i
arm64: Simplify do_notify_resume() DAIF masking
In do_notify_resume, we handle _TIF_NEED_RESCHED differently from all other flags, leaving IRQ+FIQ masked when calling into schedule(). This masking is a historical artifact, and it is not currently necessary to mask IRQ+FIQ when calling into schedule (as evidenced by the generic exit_to_user_mode_loop(), which unmasks IRQs before checking _TIF_NEED_RESCHED and calling schedule()).
This patch removes the special case for _TIF_NEED_RESCHED, moving this check into the main loop such that schedule() will be called from a regular process context with IRQ+FIQ unmasked. This is a minor simplification to do_notify_resume() and brings it into line with the generic exit_to_user_mode_loop() logic. This will also aid subsequent rework of DAIF management.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240206123848.1696480-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Itaru Kitayama <itaru.kitayama@linux.dev>
show more ...
|
#
61da7c8e |
| 30-Jan-2024 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Don't assume that TIF_SVE means we saved SVE state
When we are in a syscall we will only save the FPSIMD subset even though the task still has access to the full register set, and on c
arm64/signal: Don't assume that TIF_SVE means we saved SVE state
When we are in a syscall we will only save the FPSIMD subset even though the task still has access to the full register set, and on context switch we will only remove TIF_SVE when loading the register state. This means that the signal handling code should not assume that TIF_SVE means that the register state is stored in SVE format, it should instead check the format that was recorded during save.
Fixes: 8c845e273104 ("arm64/sve: Leave SVE enabled on syscall if we don't context switch") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240130-arm64-sve-signal-regs-v2-1-9fc6f9502782@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
5d0a8d2f |
| 10-Aug-2023 |
Mark Brown <broonie@kernel.org> |
arm64/ptrace: Ensure that SME is set up for target when writing SSVE state
When we use NT_ARM_SSVE to either enable streaming mode or change the vector length for a process we do not currently do an
arm64/ptrace: Ensure that SME is set up for target when writing SSVE state
When we use NT_ARM_SSVE to either enable streaming mode or change the vector length for a process we do not currently do anything to ensure that there is storage allocated for the SME specific register state. If the task had not previously used SME or we changed the vector length then the task will not have had TIF_SME set or backing storage for ZA/ZT allocated, resulting in inconsistent register sizes when saving state and spurious traps which flush the newly set register state.
We should set TIF_SME to disable traps and ensure that storage is allocated for ZA and ZT if it is not already allocated. This requires modifying sme_alloc() to make the flush of any existing register state optional so we don't disturb existing state for ZA and ZT.
Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Reported-by: David Spickett <David.Spickett@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> # 5.19.x Link: https://lore.kernel.org/r/20230810-arm64-fix-ptrace-race-v1-1-a5361fad2bd6@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
a5f6c2ac |
| 13-Jun-2023 |
Rick Edgecombe <rick.p.edgecombe@intel.com> |
x86/shstk: Add user control-protection fault handler
A control-protection fault is triggered when a control-flow transfer attempt violates Shadow Stack or Indirect Branch Tracking constraints. For e
x86/shstk: Add user control-protection fault handler
A control-protection fault is triggered when a control-flow transfer attempt violates Shadow Stack or Indirect Branch Tracking constraints. For example, the return address for a RET instruction differs from the copy on the shadow stack.
There already exists a control-protection fault handler for handling kernel IBT faults. Refactor this fault handler into separate user and kernel handlers, like the page fault handler. Add a control-protection handler for usermode. To avoid ifdeffery, put them both in a new file cet.c, which is compiled in the case of either of the two CET features supported in the kernel: kernel IBT or user mode shadow stack. Move some static inline functions from traps.c into a header so they can be used in cet.c.
Opportunistically fix a comment in the kernel IBT part of the fault handler that is on the end of the line instead of preceding it.
Keep the same behavior for the kernel side of the fault handler, except for converting a BUG to a WARN in the case of a #CP happening when the feature is missing. This unifies the behavior with the new shadow stack code, and also prevents the kernel from crashing under this situation which is potentially recoverable.
The control-protection fault handler works in a similar way as the general protection fault handler. It provides the si_code SEGV_CPERR to the signal handler.
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Tested-by: John Allen <john.allen@amd.com> Tested-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/all/20230613001108.3040476-28-rick.p.edgecombe%40intel.com
show more ...
|
#
616cb2f4 |
| 22-Jun-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Restore TPIDR2 register rather than memory state
Currently when restoring the TPIDR2 signal context we set the new value from the signal frame in the thread data structure but not the
arm64/signal: Restore TPIDR2 register rather than memory state
Currently when restoring the TPIDR2 signal context we set the new value from the signal frame in the thread data structure but not the register, following the pattern for the rest of the data we are restoring. This does not work in the case of TPIDR2, the register always has the value for the current task. This means that either we return to userspace and ignore the new value or we context switch and save the register value on top of the newly restored value.
Load the value from the signal context into the register instead.
Fixes: 39e54499280f ("arm64/signal: Include TPIDR2 in the signal context") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> # 6.3.x Link: https://lore.kernel.org/r/20230621-arm64-fix-tpidr2-signal-restore-v2-1-c8e8fcc10302@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
8ada7aab |
| 16-May-2023 |
Arnd Bergmann <arnd@arndb.de> |
arm64: signal: include asm/exception.h
The do_notify_resume() is in a header that is not included for the definition, which causes a W=1 warning:
arch/arm64/kernel/signal.c:1280:6: error: no previo
arm64: signal: include asm/exception.h
The do_notify_resume() is in a header that is not included for the definition, which causes a W=1 warning:
arch/arm64/kernel/signal.c:1280:6: error: no previous prototype for 'do_notify_resume' [-Werror=missing-prototypes]
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20230516160642.523862-14-arnd@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
19e99e7d |
| 17-Mar-2023 |
Dongxu Sun <sundongxu3@huawei.com> |
arm64/signal: Alloc tpidr2 sigframe after checking system_supports_tpidr2()
Move tpidr2 sigframe allocation from under the checking of system_supports_sme() to the checking of system_supports_tpidr2
arm64/signal: Alloc tpidr2 sigframe after checking system_supports_tpidr2()
Move tpidr2 sigframe allocation from under the checking of system_supports_sme() to the checking of system_supports_tpidr2().
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230317124915.1263-3-sundongxu3@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
e9d14f3f |
| 17-Mar-2023 |
Dongxu Sun <sundongxu3@huawei.com> |
arm64/signal: Use system_supports_tpidr2() to check TPIDR2
Since commit a9d6915859501("arm64/sme: Implement support for TPIDR2"), We introduced system_supports_tpidr2() for TPIDR2 handling. Let's us
arm64/signal: Use system_supports_tpidr2() to check TPIDR2
Since commit a9d6915859501("arm64/sme: Implement support for TPIDR2"), We introduced system_supports_tpidr2() for TPIDR2 handling. Let's use the specific check instead.
No functional changes.
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230317124915.1263-2-sundongxu3@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
ad678be4 |
| 31-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Only read new data when parsing the ZT context
When we parse the ZT signal context we read the entire context from userspace, including the generic signal context header which was alre
arm64/signal: Only read new data when parsing the ZT context
When we parse the ZT signal context we read the entire context from userspace, including the generic signal context header which was already read by parse_user_sigframe() and padding bytes that we ignore. Avoid the possibility of relying on the second read of the data read twice by only reading the data which we are actually going to use.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221212-arm64-signal-cleanup-v3-7-4545c94b20ff@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
24d68345 |
| 31-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Only read new data when parsing the ZA context
When we parse the ZA signal context we read the entire context from userspace, including the generic signal context header which was alre
arm64/signal: Only read new data when parsing the ZA context
When we parse the ZA signal context we read the entire context from userspace, including the generic signal context header which was already read by parse_user_sigframe() and padding bytes that we ignore. Avoid the possibility of relying on the second read of the data read twice by only reading the data which we are actually going to use.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221212-arm64-signal-cleanup-v3-6-4545c94b20ff@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
f3ac48aa |
| 31-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Only read new data when parsing the SVE context
When we parse the SVE signal context we read the entire context from userspace, including the generic signal context header which was al
arm64/signal: Only read new data when parsing the SVE context
When we parse the SVE signal context we read the entire context from userspace, including the generic signal context header which was already read by parse_user_sigframe() and padding bytes that we ignore. Avoid the possibility of relying on the second read of the data read twice by only reading the data which we are actually going to use.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221212-arm64-signal-cleanup-v3-5-4545c94b20ff@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
b57682b3 |
| 31-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Avoid rereading context frame sizes
We need to read the sizes of the signal context frames as part of parsing the overall signal context in parse_user_sigframe(). In the cases where we
arm64/signal: Avoid rereading context frame sizes
We need to read the sizes of the signal context frames as part of parsing the overall signal context in parse_user_sigframe(). In the cases where we defer frame specific parsing to other functions those functions (other than the recently added TPIDR2 parser) reread the size and validate the version they read, opening the possibility that the value may change. Avoid this possibility by passing the size read in parse_user_sigframe() through user_ctxs and referring to that.
For consistency we move the size check for the TPIDR2 context into the TPIDR2 parsing function.
Note that for SVE, ZA and ZT contexts we still read the size again but after this change we no longer use the value, further changes will avoid the read.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221212-arm64-signal-cleanup-v3-4-4545c94b20ff@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
4e4e9304 |
| 31-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Make interface for restore_fpsimd_context() consistent
Instead of taking a pointer to struct user_ctxs like the other two restore_blah_context() functions the FPSIMD function takes a p
arm64/signal: Make interface for restore_fpsimd_context() consistent
Instead of taking a pointer to struct user_ctxs like the other two restore_blah_context() functions the FPSIMD function takes a pointer to the user struct it should read. Change it to be consistent with the rest, both for consistency and to prepare for changes which avoid rereading data that has already been read by the core parsing code.
There should be no functional change from this patch.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221212-arm64-signal-cleanup-v3-3-4545c94b20ff@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
0eb23720 |
| 31-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Remove redundant size validation from parse_user_sigframe()
There is some minimal size validation in parse_user_sigframe() however all of the individual parsing functions perform frame
arm64/signal: Remove redundant size validation from parse_user_sigframe()
There is some minimal size validation in parse_user_sigframe() however all of the individual parsing functions perform frame specific validation of the sizing information, remove the frame specific size checks in the core so that there isn't any confusion about what we validate for size.
Since the checks in the SVE and ZA parsing are after we have read the relevant context and since they won't report an error if the frame is undersized they are adjusted to check for this before doing anything else.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221212-arm64-signal-cleanup-v3-2-4545c94b20ff@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
92f14518 |
| 31-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Don't redundantly verify FPSIMD magic
We validate that the magic in the struct fpsimd_context is correct in restore_fpsimd_context() but this is redundant since parse_user_sigframe() u
arm64/signal: Don't redundantly verify FPSIMD magic
We validate that the magic in the struct fpsimd_context is correct in restore_fpsimd_context() but this is redundant since parse_user_sigframe() uses this magic to decide to call the function in the first place. Remove the extra validation.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221212-arm64-signal-cleanup-v3-1-4545c94b20ff@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
39e54499 |
| 27-Dec-2022 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Include TPIDR2 in the signal context
Add a new signal frame record for TPIDR2 using the same format as we already use for ESR with different magic, a header with the value from the reg
arm64/signal: Include TPIDR2 in the signal context
Add a new signal frame record for TPIDR2 using the same format as we already use for ESR with different magic, a header with the value from the register appended as the only data. If SME is supported then this record is always included.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Link: https://lore.kernel.org/r/20221208-arm64-tpidr2-sig-v3-2-c77c6c8775f4@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
ee072cf7 |
| 16-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/sme: Implement signal handling for ZT
Add a new signal context type for ZT which is present in the signal frame when ZA is enabled and ZT is supported by the system. In order to account for th
arm64/sme: Implement signal handling for ZT
Add a new signal context type for ZT which is present in the signal frame when ZA is enabled and ZT is supported by the system. In order to account for the possible addition of further ZT registers in the future we make the number of registers variable in the ABI, though currently the only possible number is 1. We could just use a bare list head for the context since the number of registers can be inferred from the size of the context but for usability and future extensibility we define a header with the number of registers and some reserved fields in it.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221208-arm64-sme2-v4-11-f2fa0aef982f@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
ce514000 |
| 16-Jan-2023 |
Mark Brown <broonie@kernel.org> |
arm64/sme: Rename za_state to sme_state
In preparation for adding support for storage for ZT0 to the thread_struct rename za_state to sme_state. Since ZT0 is accessible when PSTATE.ZA is set just li
arm64/sme: Rename za_state to sme_state
In preparation for adding support for storage for ZT0 to the thread_struct rename za_state to sme_state. Since ZT0 is accessible when PSTATE.ZA is set just like ZA itself we will extend the allocation done for ZA to cover it, avoiding the need to further expand task_struct for non-SME tasks.
No functional changes.
Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221208-arm64-sme2-v4-1-f2fa0aef982f@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
f26cd737 |
| 27-Dec-2022 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Always allocate SVE signal frames on SME only systems
Currently we only allocate space for SVE signal frames on systems that support SVE, meaning that SME only systems do not allocate
arm64/signal: Always allocate SVE signal frames on SME only systems
Currently we only allocate space for SVE signal frames on systems that support SVE, meaning that SME only systems do not allocate a signal frame for streaming mode SVE state. Change the check so space is allocated if either feature is supported.
Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221223-arm64-fix-sme-only-v1-3-938d663f69e5@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
7dde62f0 |
| 27-Dec-2022 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Always accept SVE signal frames on SME only systems
Currently we reject an attempt to restore a SVE signal frame on a system with SME but not SVE supported. This means that it is not p
arm64/signal: Always accept SVE signal frames on SME only systems
Currently we reject an attempt to restore a SVE signal frame on a system with SME but not SVE supported. This means that it is not possible to disable streaming mode via signal return as this is configured via the flags in the SVE signal context. Instead accept the signal frame, we will require it to have a vector length of 0 specified and no payload since the task will have no SVE vector length configured.
Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221223-arm64-fix-sme-only-v1-2-938d663f69e5@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
baa85152 |
| 15-Nov-2022 |
Mark Brown <broonie@kernel.org> |
arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE
When we save the state for the floating point registers this can be done in the form visible through either the FPSIMD V registe
arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE
When we save the state for the floating point registers this can be done in the form visible through either the FPSIMD V registers or the SVE Z and P registers. At present we track which format is currently used based on TIF_SVE and the SME streaming mode state but particularly in the SVE case this limits our options for optimising things, especially around syscalls. Introduce a new enum which we place together with saved floating point state in both thread_struct and the KVM guest state which explicitly states which format is active and keep it up to date when we change it.
At present we do not use this state except to verify that it has the expected value when loading the state, future patches will introduce functional changes.
Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221115094640.112848-3-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
826a4fdd |
| 17-Aug-2022 |
Mark Brown <broonie@kernel.org> |
arm64/sme: Don't flush SVE register state when allocating SME storage
Currently when taking a SME access trap we allocate storage for the SVE register state in order to be able to handle storage of
arm64/sme: Don't flush SVE register state when allocating SME storage
Currently when taking a SME access trap we allocate storage for the SVE register state in order to be able to handle storage of streaming mode SVE. Due to the original usage in a purely SVE context the SVE register state allocation this also flushes the register state for SVE if storage was already allocated but in the SME context this is not desirable. For a SME access trap to be taken the task must not be in streaming mode so either there already is SVE register state present for regular SVE mode which would be corrupted or the task does not have TIF_SVE and the flush is redundant.
Fix this by adding a flag to sve_alloc() indicating if we are in a SVE context and need to flush the state. Freshly allocated storage is always zeroed either way.
Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220817182324.638214-4-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
ea64baac |
| 17-Aug-2022 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Flush FPSIMD register state when disabling streaming mode
When handling a signal delivered to a context with streaming mode enabled we will disable streaming mode for the signal handle
arm64/signal: Flush FPSIMD register state when disabling streaming mode
When handling a signal delivered to a context with streaming mode enabled we will disable streaming mode for the signal handler, when doing so we should also flush the saved FPSIMD register state like exiting streaming mode in the hardware would do so that if that state is reloaded we get the same behaviour. Without this we will reload whatever the last FPSIMD state that was saved for the task was.
Fixes: 40a8e87bb328 ("arm64/sme: Disable ZA and streaming mode when handling signals") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220817182324.638214-3-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|