#
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 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>
|
#
6e4596c4 |
|
12-Jun-2023 |
Jonathan Corbet <corbet@lwn.net> |
arm64: Fix dangling references to Documentation/arm64 The arm64 documentation has moved under Documentation/arch/; fix up references in the arm64 subtree to match. Cc: Will Deacon <will@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: linux-efi@vger.kernel.org Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
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 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>
|
#
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 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>
|
#
9e75e74b |
|
31-Oct-2022 |
Mark Brown <broonie@kernel.org> |
arm64/signal: Document our convention for choosing magic numbers Szabolcs Nagy has pointed out that most of our signal frame magic numbers are chosen to be meaningful ASCII when dumped to aid manual parsing. This seems sensible since it might help someone parsing things out, let's document it so people implementing new signal contexts are aware of it and are more likely to follow it. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221031192450.826159-1-broonie@kernel.org [will: Fixed typo and tweaked wording] Signed-off-by: Will Deacon <will@kernel.org>
|
#
39782210 |
|
18-Apr-2022 |
Mark Brown <broonie@kernel.org> |
arm64/sme: Implement ZA signal handling Implement support for ZA in signal handling in a very similar way to how we implement support for SVE registers, using a signal context structure with optional register state after it. Where present this register state stores the ZA matrix as a series of horizontal vectors numbered from 0 to VL/8 in the endinanness independent format used for vectors. As with SVE we do not allow changes in the vector length during signal return but we do allow ZA to be enabled or disabled. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-20-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
85ed24da |
|
18-Apr-2022 |
Mark Brown <broonie@kernel.org> |
arm64/sme: Implement streaming SVE signal handling When in streaming mode we have the same set of SVE registers as we do in regular SVE mode with the exception of FFR and the use of the SME vector length. Provide signal handling for these registers by taking one of the reserved words in the SVE signal context as a flags field and defining a flag which is set for streaming mode. When the flag is set the vector length is set to the streaming mode vector length and we save and restore streaming mode data. We support entering or leaving streaming mode based on the value of the flag but do not support changing the vector length, this is not currently supported SVE signal handling. We could instead allocate a separate record in the signal frame for the streaming mode SVE context but this inflates the size of the maximal signal frame required and adds complication when validating signal frames from userspace, especially given the current structure of the code. Any implementation of support for streaming mode vectors in signals will have some potential for causing issues for applications that attempt to handle SVE vectors in signals, use streaming mode but do not understand streaming mode in their signal handling code, it is hard to identify a case that is clearly better than any other - they all have cases where they could cause unexpected register corruption or faults. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-19-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
1a9ea25d |
|
25-Jul-2020 |
Randy Dunlap <rdunlap@infradead.org> |
arm64: sigcontext.h: delete duplicated word Drop the repeated word "the". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20200726003207.20253-4-rdunlap@infradead.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
b693d0b3 |
|
12-Jun-2019 |
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
docs: arm64: convert docs to ReST and rename to .rst The documentation is in a format that is very close to ReST format. The conversion is actually: - add blank lines in order to identify paragraphs; - fixing tables markups; - adding some lists markups; - marking literal blocks; - adjust some title markups. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
#
41040cf7 |
|
12-Jun-2019 |
Dave Martin <Dave.Martin@arm.com> |
arm64/sve: Fix missing SVE/FPSIMD endianness conversions The in-memory representation of SVE and FPSIMD registers is different: the FPSIMD V-registers are stored as single 128-bit host-endian values, whereas SVE registers are stored in an endianness-invariant byte order. This means that the two representations differ when running on a big-endian host. But we blindly copy data from one representation to another when converting between the two, resulting in the register contents being unintentionally byteswapped in certain situations. Currently this can be triggered by the first SVE instruction after a syscall, for example (though the potential trigger points may vary in future). So, fix the conversion functions fpsimd_to_sve(), sve_to_fpsimd() and sve_sync_from_fpsimd_zeropad() to swab where appropriate. There is no common swahl128() or swab128() that we could use here. Maybe it would be worth making this generic, but for now add a simple local hack. Since the byte order differences are exposed in ABI, also clarify the documentation. Cc: Alex Bennée <alex.bennee@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Alan Hayward <alan.hayward@arm.com> Cc: Julien Grall <julien.grall@arm.com> Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") Fixes: 8cd969d28fd2 ("arm64/sve: Signal handling support") Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support") Signed-off-by: Dave Martin <Dave.Martin@arm.com> [will: Fix typos in comments and docs spotted by Julien] Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
9966a05c |
|
04-Jan-2019 |
Dave Martin <Dave.Martin@arm.com> |
arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h> Currently, <uapi/asm/sigcontext.h> provides common definitions for describing SVE context structures that are also used by the ptrace definitions in <uapi/asm/ptrace.h>. For this reason, a #include of <asm/sigcontext.h> was added in ptrace.h, but it this turns out that this can interact badly with userspace code that tries to include ptrace.h on top of the libc headers (which may provide their own shadow definitions for sigcontext.h). To make the headers easier for userspace to consume, this patch bounces the common definitions into an __SVE_* namespace and moves them to a backend header <uapi/asm/sve_context.h> that can be included by the other headers as appropriate. This should allow ptrace.h to be used alongside libc's sigcontext.h (if any) without ill effects. This should make the situation unambiguous: <asm/sigcontext.h> is the header to include for the sigframe-specific definitions, while <asm/ptrace.h> is the header to include for ptrace-specific definitions. To avoid conflicting with existing usage, <asm/sigcontext.h> remains the canonical way to get the common definitions for SVE_VQ_MIN, sve_vq_from_vl() etc., both in userspace and in the kernel: relying on these being defined as a side effect of including just <asm/ptrace.h> was never intended to be safe. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
ce699081 |
|
31-Oct-2017 |
Dave Martin <Dave.Martin@arm.com> |
arm64/sve: Add documentation This patch adds basic documentation of the user/kernel interface provided by the for SVE. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Alan Hayward <alan.hayward@arm.com> Cc: Alex Bennée <alex.bennee@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com> Cc: linux-api@vger.kernel.org Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
d0b8cd31 |
|
31-Oct-2017 |
Dave Martin <Dave.Martin@arm.com> |
arm64/sve: Signal frame and context structure definition This patch defines the representation that will be used for the SVE register state in the signal frame, and implements support for saving and restoring the SVE registers around signals. The same layout will also be used for the in-kernel task state. Due to the variability of the SVE vector length, it is not possible to define a fixed C struct to describe all the registers. Instead, Macros are defined in sigcontext.h to facilitate access to the parts of the structure. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
e2be04c7 |
|
01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX license identifier to uapi header files with a license Many user space API headers have licensing information, which is either incomplete, badly formatted or just a shorthand for referring to the license under which the file is supposed to be. This makes it hard for compliance tools to determine the correct license. Update these files with an SPDX license identifier. The identifier was chosen based on the license information in the file. GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license identifier with the added 'WITH Linux-syscall-note' exception, which is the officially assigned exception identifier for the kernel syscall exception: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". This exception makes it possible to include GPL headers into non GPL code, without confusing license compliance tools. Headers which have either explicit dual licensing or are just licensed under a non GPL license are updated with the corresponding SPDX identifier and the GPLv2 with syscall exception identifier. The format is: ((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE) SPDX license identifiers are a legally binding shorthand, which can be used instead of the full boiler plate text. The update does not remove existing license information as this has to be done on a case by case basis and the copyright holders might have to be consulted. This will happen in a separate step. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. See the previous patch in this series for the methodology of how this patch was researched. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
33f08261 |
|
20-Jun-2017 |
Dave Martin <Dave.Martin@arm.com> |
arm64: signal: Allow expansion of the signal frame This patch defines an extra_context signal frame record that can be used to describe an expanded signal frame, and modifies the context block allocator and signal frame setup and parsing code to create, populate, parse and decode this block as necessary. To avoid abuse by userspace, parse_user_sigframe() attempts to ensure that: * no more than one extra_context is accepted; * the extra context data is a sensible size, and properly placed and aligned. The extra_context data is required to start at the first 16-byte aligned address immediately after the dummy terminator record following extra_context in rt_sigframe.__reserved[] (as ensured during signal delivery). This serves as a sanity-check that the signal frame has not been moved or copied without taking the extra data into account. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> [will: add __force annotation when casting extra_datap to __user pointer] Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
bb4322f7 |
|
15-Jun-2017 |
Dave Martin <Dave.Martin@arm.com> |
arm64: signal: factor out signal frame record allocation This patch factors out the allocator for signal frame optional records into a separate function, to ensure consistency and facilitate later expansion. No overrun checking is currently done, because the allocation is in user memory and anyway the kernel never tries to allocate enough space in the signal frame yet for an overrun to occur. This behaviour will be refined in future patches. The approach taken in this patch to allocation of the terminator record is not very clean: this will also be replaced in subsequent patches. For future extension, a comment is added in sigcontext.h documenting the current static allocations in __reserved[]. This will be important for determining under what circumstances userspace may or may not see an expanded signal frame. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
5e406450 |
|
11-Jun-2014 |
Mark Salter <msalter@redhat.com> |
arm64: fix build error in sigcontext.h I'm seeing this build failure for arm64: CC [M] Documentation/filesystems/configfs/configfs_example_macros.o In file included from /usr/include/bits/sigcontext.h:27:0, from /usr/include/signal.h:340, from /usr/include/sys/wait.h:30, from Documentation/accounting/getdelays.c:24: .../linux/usr/include/asm/sigcontext.h:61:2: error: unknown type name ‘u64’ u64 esr; ^ make[2]: *** [Documentation/accounting/getdelays] Error 1 This was introduced by commit 15af1942dd61ee23: arm64: Expose ESR_EL1 information to user when SIGSEGV/SIGBUS Using __u64 instead of u64 fixes the problem. Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
15af1942 |
|
16-Sep-2013 |
Catalin Marinas <catalin.marinas@arm.com> |
arm64: Expose ESR_EL1 information to user when SIGSEGV/SIGBUS This information is useful for instruction emulators to detect read/write and access size without having to decode the faulting instruction. The current patch exports it via sigcontext (struct esr_context) and is only valid for SIGSEGV and SIGBUS. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
4262a727 |
|
11-Oct-2012 |
David Howells <dhowells@redhat.com> |
UAPI: (Scripted) Disintegrate arch/arm64/include/asm Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
|