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 3/6] arm64: signal: factor out signal frame record allocation Date: Wed, 12 Apr 2017 18:01:12 +0100 [thread overview] Message-ID: <1492016495-19689-3-git-send-email-Dave.Martin@arm.com> (raw) In-Reply-To: <1492016495-19689-1-git-send-email-Dave.Martin@arm.com> This patch factors out the allocator for signal frame optional records into a separate function, to ensure consistency and facilitate later expansion of the signal frame, so that the allocation mechanism can be elaborated more easily in future patches. No overrun checking is currently done, because the allocation is in user memory, and because the kernel statically does not attempt 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 table is added 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. Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- arch/arm64/include/uapi/asm/sigcontext.h | 19 ++++++++++++++ arch/arm64/kernel/signal.c | 43 ++++++++++++++++++++++++++------ 2 files changed, 55 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h index ee469be..1328a2c 100644 --- a/arch/arm64/include/uapi/asm/sigcontext.h +++ b/arch/arm64/include/uapi/asm/sigcontext.h @@ -34,6 +34,25 @@ struct sigcontext { }; /* + * Allocation of __reserved[]: + * (Note: records do not necessarily occur in the order shown here.) + * + * size description + * + * 0x210 fpsimd_context + * 0x10 esr_context + * 0x10 terminator (null _aarch64_ctx) + * + * 0xdd0 (reserved for future allocation) + * + * New records that can exceed this space need to be opt-in for userspace, so + * that an expanded signal frame is not generated unexpectedly. The mechanism + * for opting in will depend on the extension that generates each new record. + * The above table documents the maximum set and sizes of records than can be + * generated when userspace does not opt in for any such extension. + */ + +/* * Header to be used at the beginning of structures extending the user * context. Such structures must be placed after the rt_sigframe on the stack * and be 16-byte aligned. The last structure must be a dummy one with the diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 6202753..47592af 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -75,6 +75,22 @@ static size_t sigframe_size(struct rt_sigframe_user_layout const *user) return round_up(max(user->size, sizeof(struct rt_sigframe)), 16); } +/* + * Allocate space for an optional record of <size> bytes in the user + * signal frame. The offset from the signal frame base address to the + * allocated block is assigned to *offset. + */ +static int sigframe_alloc(struct rt_sigframe_user_layout *user, + unsigned long *offset, size_t size) +{ + size_t padded_size = round_up(size, 16); + + *offset = user->size; + user->size += padded_size; + + return 0; +} + static void __user *apply_user_offset( struct rt_sigframe_user_layout const *user, unsigned long offset) { @@ -283,19 +299,32 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs) /* Determine the layout of optional records in the signal frame */ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user) { - user->fpsimd_offset = user->size; - user->size += round_up(sizeof(struct fpsimd_context), 16); + int err; + + err = sigframe_alloc(user, &user->fpsimd_offset, + sizeof(struct fpsimd_context)); + if (err) + return err; /* fault information, if valid */ if (current->thread.fault_code) { - user->esr_offset = user->size; - user->size += round_up(sizeof(struct esr_context), 16); + err = sigframe_alloc(user, &user->esr_offset, + sizeof(struct esr_context)); + if (err) + return err; } - /* set the "end" magic */ - user->end_offset = user->size; + /* + * Allocate space for the terminator record. + * HACK: here we undo the reservation of space for the end record. + * This bodge should be replaced with a cleaner approach later on. + */ + user->limit = offsetof(struct rt_sigframe, uc.uc_mcontext.__reserved) + + sizeof(user->sigframe->uc.uc_mcontext.__reserved); - return 0; + err = sigframe_alloc(user, &user->end_offset, + sizeof(struct _aarch64_ctx)); + return err; } -- 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 3/6] arm64: signal: factor out signal frame record allocation Date: Wed, 12 Apr 2017 18:01:12 +0100 [thread overview] Message-ID: <1492016495-19689-3-git-send-email-Dave.Martin@arm.com> (raw) In-Reply-To: <1492016495-19689-1-git-send-email-Dave.Martin@arm.com> This patch factors out the allocator for signal frame optional records into a separate function, to ensure consistency and facilitate later expansion of the signal frame, so that the allocation mechanism can be elaborated more easily in future patches. No overrun checking is currently done, because the allocation is in user memory, and because the kernel statically does not attempt 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 table is added 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. Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- arch/arm64/include/uapi/asm/sigcontext.h | 19 ++++++++++++++ arch/arm64/kernel/signal.c | 43 ++++++++++++++++++++++++++------ 2 files changed, 55 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h index ee469be..1328a2c 100644 --- a/arch/arm64/include/uapi/asm/sigcontext.h +++ b/arch/arm64/include/uapi/asm/sigcontext.h @@ -34,6 +34,25 @@ struct sigcontext { }; /* + * Allocation of __reserved[]: + * (Note: records do not necessarily occur in the order shown here.) + * + * size description + * + * 0x210 fpsimd_context + * 0x10 esr_context + * 0x10 terminator (null _aarch64_ctx) + * + * 0xdd0 (reserved for future allocation) + * + * New records that can exceed this space need to be opt-in for userspace, so + * that an expanded signal frame is not generated unexpectedly. The mechanism + * for opting in will depend on the extension that generates each new record. + * The above table documents the maximum set and sizes of records than can be + * generated when userspace does not opt in for any such extension. + */ + +/* * Header to be used at the beginning of structures extending the user * context. Such structures must be placed after the rt_sigframe on the stack * and be 16-byte aligned. The last structure must be a dummy one with the diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 6202753..47592af 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -75,6 +75,22 @@ static size_t sigframe_size(struct rt_sigframe_user_layout const *user) return round_up(max(user->size, sizeof(struct rt_sigframe)), 16); } +/* + * Allocate space for an optional record of <size> bytes in the user + * signal frame. The offset from the signal frame base address to the + * allocated block is assigned to *offset. + */ +static int sigframe_alloc(struct rt_sigframe_user_layout *user, + unsigned long *offset, size_t size) +{ + size_t padded_size = round_up(size, 16); + + *offset = user->size; + user->size += padded_size; + + return 0; +} + static void __user *apply_user_offset( struct rt_sigframe_user_layout const *user, unsigned long offset) { @@ -283,19 +299,32 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs) /* Determine the layout of optional records in the signal frame */ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user) { - user->fpsimd_offset = user->size; - user->size += round_up(sizeof(struct fpsimd_context), 16); + int err; + + err = sigframe_alloc(user, &user->fpsimd_offset, + sizeof(struct fpsimd_context)); + if (err) + return err; /* fault information, if valid */ if (current->thread.fault_code) { - user->esr_offset = user->size; - user->size += round_up(sizeof(struct esr_context), 16); + err = sigframe_alloc(user, &user->esr_offset, + sizeof(struct esr_context)); + if (err) + return err; } - /* set the "end" magic */ - user->end_offset = user->size; + /* + * Allocate space for the terminator record. + * HACK: here we undo the reservation of space for the end record. + * This bodge should be replaced with a cleaner approach later on. + */ + user->limit = offsetof(struct rt_sigframe, uc.uc_mcontext.__reserved) + + sizeof(user->sigframe->uc.uc_mcontext.__reserved); - return 0; + err = sigframe_alloc(user, &user->end_offset, + sizeof(struct _aarch64_ctx)); + return err; } -- 2.1.4
next prev parent reply other threads:[~2017-04-12 17:02 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-12 16:56 [RFC PATCH v2 0/6] Signal frame expansion support Dave Martin 2017-04-12 16:56 ` 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 ` Dave Martin [this message] 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 ` [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=1492016495-19689-3-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.