linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

      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).