From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 00/11] arm64: Add a compat vDSO
Date: Fri, 17 Feb 2017 17:16:34 +0000 [thread overview]
Message-ID: <20170217171634.GM15431@arm.com> (raw)
In-Reply-To: <20161206160353.14581-1-kevin.brodsky@arm.com>
On Tue, Dec 06, 2016 at 04:03:42PM +0000, Kevin Brodsky wrote:
> Hi,
Hi Kevin,
> This series adds support for a compat (AArch32) vDSO, providing two
> userspace functionalities to compat processes:
>
> * "Virtual" time syscalls (gettimeofday and clock_gettime). The
> implementation is an adaptation of the arm vDSO (vgettimeofday.c),
> sharing the data page with the 64-bit vDSO.
>
> * sigreturn trampolines, following the example of the 64-bit vDSO
> (sigreturn.S), but slightly more complicated because we provide A32
> and T32 variants for both sigreturn and rt_sigreturn, and appropriate
> arm-specific unwinding directives.
>
> The first point brings the performance improvement expected of a vDSO,
> by implementing time syscalls directly in userspace. The second point
> allows to provide unwinding information for sigreturn trampolines,
> achieving feature parity with the trampolines provided by glibc.
>
> Unfortunately, this time we cannot escape using a 32-bit toolchain. To
> build the compat VDSO, CONFIG_COMPAT_VDSO must be set *and*
> CROSS_COMPILE_ARM32 must be defined to the prefix of a 32-bit compiler.
> Failure to do so will not prevent building the kernel, but a warning
> will be printed and the compat vDSO will not be built.
>
> v3 is a major refactor of the series. The main change is that the kuser
> helpers are no longer mutually exclusive with the 32-bit vDSO, and can
> be disabled independently of the 32-bit vDSO (they are kept enabled by
> default). To this end, the "old" sigreturn trampolines have been moved
> out of the [vectors] page into an independent [sigreturn] page, similar
> to [sigpage] on arm. The [vectors] page is now [kuserhelpers], and its
> presence is controlled by CONFIG_KUSER_HELPERS. The [sigreturn] page is
> only present when the 32-bit vDSO is not included (the latter provides
> its own sigreturn trampolines with unwinding information). The following
> table summarises which pages are now added in 32-bit processes:
>
> +----------------+----------------+----------------+
> | CONFIG | !VDSO32 | VDSO32 |
> +----------------+----------------+----------------+
> | !KUSER_HELPERS | [sigreturn] | [vvar] |
> | | | [vdso] |
> +----------------+----------------+----------------+
> | KUSER_HELPERS | [sigreturn] | [vvar] |
> | | [kuserhelpers] | [vdso] |
> | | | [kuserhelpers] |
> +----------------+----------------+----------------+
Why is this different to arch/arm/? The idea of the COMPAT layer is to
do the same thing as arch/arm, so we should use [sigpage] and [vectors]
instead of [sigreturn] and [kuserhelpers]. I also think that the /proc/maps
code assumes the "gate vma" is at the end, but that's more of a niggle
than anything else.
The big issue with this series is that I share Nathan's concerns that we're
needlessly forking code from arch/arm/, without a commitment to follow up
with the refactoring effort. So, whilst I can see that technically this is
looking pretty solid, it's a big ask to merge this into mainline as-is.
Will
prev parent reply other threads:[~2017-02-17 17:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-06 16:03 [RFC PATCH v3 00/11] arm64: Add a compat vDSO Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 01/11] arm64: compat: Remove leftover variable declaration Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 02/11] arm64: compat: Split the sigreturn trampolines and kuser helpers Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 03/11] arm64: compat: Add CONFIG_KUSER_HELPERS Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 04/11] arm64: Refactor vDSO init/setup Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 05/11] arm64: compat: Add time-related syscall numbers Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 06/11] arm64: compat: Expose offset to registers in sigframes Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 07/11] arm64: compat: Add a 32-bit vDSO Kevin Brodsky
2016-12-07 18:51 ` Nathan Lynch
2016-12-08 10:59 ` Kevin Brodsky
2016-12-08 17:02 ` Nathan Lynch
2016-12-06 16:03 ` [RFC PATCH v3 08/11] arm64: compat: 32-bit vDSO setup Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 09/11] arm64: elf: Set AT_SYSINFO_EHDR in compat processes Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 10/11] arm64: compat: Use vDSO sigreturn trampolines if available Kevin Brodsky
2016-12-06 16:03 ` [RFC PATCH v3 11/11] arm64: Wire up and expose the new compat vDSO Kevin Brodsky
2017-02-17 17:16 ` Will Deacon [this message]
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=20170217171634.GM15431@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).