From: Catalin Marinas <catalin.marinas@arm.com> To: Dave Martin <Dave.Martin@arm.com> Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, Will Deacon <will.deacon@arm.com> Subject: Re: [RFC PATCH v2 4/6] arm64: signal: Allocate extra sigcontext space as needed Date: Fri, 12 May 2017 17:57:24 +0100 [thread overview] Message-ID: <20170512165724.GB8387@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <1492016495-19689-4-git-send-email-Dave.Martin@arm.com> Hi Dave, On Wed, Apr 12, 2017 at 06:01:13PM +0100, Dave P Martin wrote: > --- a/arch/arm64/include/uapi/asm/sigcontext.h > +++ b/arch/arm64/include/uapi/asm/sigcontext.h > @@ -80,4 +80,31 @@ struct esr_context { > __u64 esr; > }; > > +/* > + * Pointer to extra space for additional structures that don't fit in > + * sigcontext.__reserved[]. Note: > + * > + * 1) fpsimd_context, esr_context and extra_context must be placed in > + * sigcontext.__reserved[] if present. They cannot be placed in the > + * extra space. Any other record can be placed either in the extra > + * space or in sigcontext.__reserved[]. > + * > + * 2) There must not be more than one extra_context. > + * > + * 3) If extra_context is present, it must be followed immediately in > + * sigcontext.__reserved[] by the terminating null _aarch64_ctx (i.e., > + * extra_context must be the last record in sigcontext.__reserved[] > + * except for the terminator). > + * > + * 4) The extra space must itself be terminated with a null > + * _aarch64_ctx. > + */ IIUC, if we need to save some state that doesn't fit in what's left of sigcontext.__reserved[] (e.g. SVE with 1024-bit vector length), we ignore the available space and go for a memory block following the end of sigcontext.__reserved[] + 16. Is there a reason we can't store the new state across the end of sigcontext.__reserved[] and move fp/lr at the end of the new frame? I'm not sure the fp/lr position immediately after __reserved[] counts as ABI. > +#define EXTRA_MAGIC 0x45585401 > + > +struct extra_context { > + struct _aarch64_ctx head; > + void __user *data; /* 16-byte aligned pointer to extra space */ "__user" is a kernel-only attribute, we shouldn't expose it in a uapi header. > + __u32 size; /* size in bytes of the extra space */ > +}; Do we need the size of the extra space? Can we not infer it anyway by walking the contexts save there? Surely we don't expect more than one extra context. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 4/6] arm64: signal: Allocate extra sigcontext space as needed Date: Fri, 12 May 2017 17:57:24 +0100 [thread overview] Message-ID: <20170512165724.GB8387@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <1492016495-19689-4-git-send-email-Dave.Martin@arm.com> Hi Dave, On Wed, Apr 12, 2017 at 06:01:13PM +0100, Dave P Martin wrote: > --- a/arch/arm64/include/uapi/asm/sigcontext.h > +++ b/arch/arm64/include/uapi/asm/sigcontext.h > @@ -80,4 +80,31 @@ struct esr_context { > __u64 esr; > }; > > +/* > + * Pointer to extra space for additional structures that don't fit in > + * sigcontext.__reserved[]. Note: > + * > + * 1) fpsimd_context, esr_context and extra_context must be placed in > + * sigcontext.__reserved[] if present. They cannot be placed in the > + * extra space. Any other record can be placed either in the extra > + * space or in sigcontext.__reserved[]. > + * > + * 2) There must not be more than one extra_context. > + * > + * 3) If extra_context is present, it must be followed immediately in > + * sigcontext.__reserved[] by the terminating null _aarch64_ctx (i.e., > + * extra_context must be the last record in sigcontext.__reserved[] > + * except for the terminator). > + * > + * 4) The extra space must itself be terminated with a null > + * _aarch64_ctx. > + */ IIUC, if we need to save some state that doesn't fit in what's left of sigcontext.__reserved[] (e.g. SVE with 1024-bit vector length), we ignore the available space and go for a memory block following the end of sigcontext.__reserved[] + 16. Is there a reason we can't store the new state across the end of sigcontext.__reserved[] and move fp/lr at the end of the new frame? I'm not sure the fp/lr position immediately after __reserved[] counts as ABI. > +#define EXTRA_MAGIC 0x45585401 > + > +struct extra_context { > + struct _aarch64_ctx head; > + void __user *data; /* 16-byte aligned pointer to extra space */ "__user" is a kernel-only attribute, we shouldn't expose it in a uapi header. > + __u32 size; /* size in bytes of the extra space */ > +}; Do we need the size of the extra space? Can we not infer it anyway by walking the contexts save there? Surely we don't expect more than one extra context. -- Catalin
next prev parent reply other threads:[~2017-05-12 16:57 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 ` [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 [this message] 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=20170512165724.GB8387@e104818-lin.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=Dave.Martin@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.