From: Dave Martin <Dave.Martin@arm.com> To: linux-arm-kernel@lists.infradead.org Cc: linux-arch@vger.kernel.org, Will Deacon <will.deacon@arm.com>, Catalin Marinas <catalin.marinas@arm.com> Subject: [RFC PATCH v2 0/6] Signal frame expansion support Date: Wed, 12 Apr 2017 17:56:53 +0100 [thread overview] Message-ID: <1492016239-19511-1-git-send-email-Dave.Martin@arm.com> (raw) (Note: This is an arm64-specific series, but the concepts introduced may be of interest to other arches -- see in particular patch 6.) Blurb: An architecture advertises the maximum possible signal frame size via the MINSIGSTKSZ #define (mandated by POSIX). However, CPU architecture extensions may increase the amount of space required to store the interrupted context when a signal is delivered. Eventually the amount of space needed in the signal frame may exceed MINSIGSTKSZ -- whether and when this happens is largely a matter of luck, depending on the initial guess for MINSIGSTKSZ and the evolution of that particular CPU architecture. Unfortunately MINSIGSTKSZ cannot be changed without an ABI break, and POSIX provides no mechanism for migration. arm64 initially reserved 4KB of space in the signal frame for extensions, of which about 0.5KB is allocated to the FP/SIMD registers initially. Depending on the vector length supported by the hardware, SVE requires up to around 8KB of space to store the full SIMD register context, which is too large to fit in the existing frame. This series adds a mechanism for optionally enlarging the signal frame (patches 4-5) and reporting the actual maximum signal frame size to userspace (patch 6). Patches 1-3 do some refactoring to support this change by abstracting the way signal frame records are allocated onto the user stack. Full backwards compatibility is not possible -- there is no way to hide the fact that the signal frame has grown -- so it is expected that support for new architecture extensions that can cause the signal frame to grow will be opt-in for userspace, in addition to using the extension mechanism defined by this series. [1] ARM Scalable Vector Extension https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture https://developer.arm.com/docs/ddi0584/latest/arm-architecture-reference-manual-supplement-the-scalable-vector-extension-sve-for-armv8-a Dave Martin (6): arm64: signal: Refactor sigcontext parsing in rt_sigreturn arm64: signal: factor frame layout and population into separate passes arm64: signal: factor out signal frame record allocation arm64: signal: Allocate extra sigcontext space as needed arm64: signal: Parse extra_context during sigreturn arm64: signal: Report signal frame size to userspace via auxv arch/arm64/include/asm/elf.h | 5 + arch/arm64/include/asm/processor.h | 3 + arch/arm64/include/uapi/asm/auxvec.h | 3 +- arch/arm64/include/uapi/asm/sigcontext.h | 50 ++++ arch/arm64/kernel/signal.c | 389 ++++++++++++++++++++++++++++--- 5 files changed, 415 insertions(+), 35 deletions(-) -- 2.1.4
WARNING: multiple messages have this Message-ID (diff)
From: Dave.Martin@arm.com (Dave Martin) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 0/6] Signal frame expansion support Date: Wed, 12 Apr 2017 17:56:53 +0100 [thread overview] Message-ID: <1492016239-19511-1-git-send-email-Dave.Martin@arm.com> (raw) (Note: This is an arm64-specific series, but the concepts introduced may be of interest to other arches -- see in particular patch 6.) Blurb: An architecture advertises the maximum possible signal frame size via the MINSIGSTKSZ #define (mandated by POSIX). However, CPU architecture extensions may increase the amount of space required to store the interrupted context when a signal is delivered. Eventually the amount of space needed in the signal frame may exceed MINSIGSTKSZ -- whether and when this happens is largely a matter of luck, depending on the initial guess for MINSIGSTKSZ and the evolution of that particular CPU architecture. Unfortunately MINSIGSTKSZ cannot be changed without an ABI break, and POSIX provides no mechanism for migration. arm64 initially reserved 4KB of space in the signal frame for extensions, of which about 0.5KB is allocated to the FP/SIMD registers initially. Depending on the vector length supported by the hardware, SVE requires up to around 8KB of space to store the full SIMD register context, which is too large to fit in the existing frame. This series adds a mechanism for optionally enlarging the signal frame (patches 4-5) and reporting the actual maximum signal frame size to userspace (patch 6). Patches 1-3 do some refactoring to support this change by abstracting the way signal frame records are allocated onto the user stack. Full backwards compatibility is not possible -- there is no way to hide the fact that the signal frame has grown -- so it is expected that support for new architecture extensions that can cause the signal frame to grow will be opt-in for userspace, in addition to using the extension mechanism defined by this series. [1] ARM Scalable Vector Extension https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture https://developer.arm.com/docs/ddi0584/latest/arm-architecture-reference-manual-supplement-the-scalable-vector-extension-sve-for-armv8-a Dave Martin (6): arm64: signal: Refactor sigcontext parsing in rt_sigreturn arm64: signal: factor frame layout and population into separate passes arm64: signal: factor out signal frame record allocation arm64: signal: Allocate extra sigcontext space as needed arm64: signal: Parse extra_context during sigreturn arm64: signal: Report signal frame size to userspace via auxv arch/arm64/include/asm/elf.h | 5 + arch/arm64/include/asm/processor.h | 3 + arch/arm64/include/uapi/asm/auxvec.h | 3 +- arch/arm64/include/uapi/asm/sigcontext.h | 50 ++++ arch/arm64/kernel/signal.c | 389 ++++++++++++++++++++++++++++--- 5 files changed, 415 insertions(+), 35 deletions(-) -- 2.1.4
next reply other threads:[~2017-04-12 16:57 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-12 16:56 Dave Martin [this message] 2017-04-12 16:56 ` [RFC PATCH v2 0/6] Signal frame expansion support Dave Martin 2017-04-12 17:01 ` [RFC PATCH v2 1/6] arm64: signal: Refactor sigcontext parsing in rt_sigreturn Dave Martin 2017-04-12 17:01 ` Dave Martin 2017-04-12 17:01 ` [RFC PATCH v2 2/6] arm64: signal: factor frame layout and population into separate passes Dave Martin 2017-04-12 17:01 ` Dave Martin 2017-04-12 17:01 ` [RFC PATCH v2 3/6] arm64: signal: factor out signal frame record allocation Dave Martin 2017-04-12 17:01 ` Dave Martin 2017-04-12 17:01 ` [RFC PATCH v2 4/6] arm64: signal: Allocate extra sigcontext space as needed Dave Martin 2017-04-12 17:01 ` Dave Martin 2017-05-12 16:57 ` Catalin Marinas 2017-05-12 16:57 ` Catalin Marinas 2017-05-15 13:24 ` Dave Martin 2017-05-15 13:24 ` Dave Martin 2017-05-23 11:30 ` Catalin Marinas 2017-05-23 11:30 ` Catalin Marinas 2017-05-26 11:37 ` Dave Martin 2017-05-26 11:37 ` Dave Martin 2017-06-05 14:17 ` Catalin Marinas 2017-06-05 14:17 ` Catalin Marinas 2017-06-06 11:37 ` Dave Martin 2017-06-06 11:37 ` Dave Martin 2017-06-06 13:58 ` Dave Martin 2017-06-06 13:58 ` Dave Martin 2017-06-06 16:15 ` Catalin Marinas 2017-06-06 16:15 ` Catalin Marinas 2017-06-06 16:15 ` Catalin Marinas 2017-06-06 16:15 ` Catalin Marinas 2017-06-08 8:46 ` Dave Martin 2017-06-08 8:46 ` Dave Martin 2017-04-12 17:01 ` [RFC PATCH v2 5/6] arm64: signal: Parse extra_context during sigreturn Dave Martin 2017-04-12 17:01 ` Dave Martin 2017-04-12 17:01 ` [RFC PATCH v2 6/6] arm64: signal: Report signal frame size to userspace via auxv Dave Martin 2017-04-12 17:01 ` Dave Martin 2017-04-20 11:49 ` [RFC PATCH v2 0/6] Signal frame expansion support Michael Ellerman 2017-04-20 11:49 ` Michael Ellerman 2017-04-20 12:45 ` Dave Martin 2017-04-20 12:45 ` Dave Martin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1492016239-19511-1-git-send-email-Dave.Martin@arm.com \ --to=dave.martin@arm.com \ --cc=catalin.marinas@arm.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.