From: Rich Felker <dalias@libc.org>
To: David Daney <ddaney.cavm@gmail.com>
Cc: libc-alpha@sourceware.org, linux-kernel@vger.kernel.org,
linux-mips@linux-mips.org, David Daney <david.daney@cavium.com>
Subject: Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.
Date: Mon, 6 Oct 2014 16:54:59 -0400 [thread overview]
Message-ID: <20141006205459.GZ23797@brightrain.aerifal.cx> (raw)
In-Reply-To: <1412627010-4311-1-git-send-email-ddaney.cavm@gmail.com>
On Mon, Oct 06, 2014 at 01:23:30PM -0700, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> In order for MIPS to be able to support a non-executable stack, we
> need to supply a method to specify a userspace area that can be used
> for executing emulated branch delay slot instructions.
>
> We add a new system call, sys_set_fpuemul_xol_area so that userspace
> threads that are using the FPU can specify the location of the FPU
> emulation out of line execution area.
>
> Background:
>
> MIPS floating point support requires that any instruction that cannot
> be directly executed by the FPU, be emulated by the kernel. Part of
> this emulation involves executing non-FPU instructions that fall in
> the delay slots of FP branch instructions. Since the beginning of
> MIPS/Linux time, this has been done by placing the instructions on the
> userspace thread stack, and executing them there, as the instructions
> must be executed in the MM context of the thread receiving the
> emulation.
>
> Because of this, the de facto MIPS Linux userspace ABI requires that
> the userspace thread have an executable stack. It is de facto,
> because it is not written anywhere that this must be the case, but it
> is never the less a requirement.
>
> Problem:
>
> How do we get MIPS Linux to use a non-executable stack in the face of
> the FPU emulation problem?
>
> Since userspace desires to change the ABI, put some of the onus on the
> userspace code. Any userspace thread desiring a non-executable stack,
> must allocate a 4-byte aligned area at least 8 bytes long with that
> has read/write/execute permissions and pass the address of that area
> to the kernel with the new sys_set_fpuemul_xol_area system call.
>
> This is similar to how we require userspace to notify the kernel of
> the value of the thread local pointer.
Userspace should play no part in this; requiring userspace to help
make special accomodations for fpu emulation largely defeats the
purpose of fpu emulation. The kernel is perfectly capable of mapping
an appropriate page. The mapping should happen at exec time, and at
clone time with CLONE_VM unless the kernel is going to handle mutual
exclusion so that only one thread can be using the page at a time.
(Using one page for the whole process, and excluding simultaneous
execution of fpu emulation in multiple threads, may be the more
practical approach.)
As an alternative, if the space of possible instruction with a delay
slot is sufficiently small, all such instructions could be mapped as
immutable code in a shared mapping, each at a fixed offset in the
mapping. I suspect this would be borderline-impractical (multiple
megabytes?), but it is the cleanest solution otherwise.
Rich
next prev parent reply other threads:[~2014-10-06 21:07 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-06 20:23 David Daney
2014-10-06 20:54 ` Rich Felker [this message]
2014-10-06 21:18 ` David Daney
2014-10-06 21:31 ` Rich Felker
2014-10-06 21:45 ` David Daney
2014-10-06 21:58 ` Rich Felker
2014-10-06 22:17 ` David Daney
2014-10-06 23:08 ` Rich Felker
2014-10-06 23:38 ` Andy Lutomirski
2014-10-06 23:48 ` David Daney
2014-10-06 23:54 ` Andy Lutomirski
2014-10-07 0:05 ` Rich Felker
2014-10-07 0:11 ` Andrew Pinski
2014-10-07 0:21 ` Rich Felker
2014-10-07 0:28 ` Andrew Pinski
2014-10-07 0:29 ` Andy Lutomirski
2014-10-07 0:32 ` David Daney
2014-10-07 0:33 ` David Daney
2014-10-07 0:48 ` Andy Lutomirski
2014-10-07 0:49 ` Rich Felker
2014-10-07 4:50 ` David Daney
2014-10-07 9:13 ` Matthew Fortune
2014-10-07 10:52 ` James Hogan
2014-10-07 11:19 ` Rich Felker
2014-10-07 16:04 ` David Daney
2014-10-07 18:32 ` Leonid Yegoshin
2014-10-07 18:43 ` David Daney
2014-10-07 19:13 ` Leonid Yegoshin
2014-10-07 18:44 ` Andy Lutomirski
2014-10-07 18:50 ` David Daney
2014-10-07 19:09 ` Rich Felker
2014-10-07 19:16 ` Leonid Yegoshin
2014-10-07 19:21 ` Rich Felker
2014-10-07 19:27 ` Leonid Yegoshin
2014-10-07 19:28 ` Andy Lutomirski
2014-10-07 20:03 ` David Daney
2014-10-08 0:22 ` Andy Lutomirski
2014-10-07 19:40 ` Matthew Fortune
2014-10-07 11:11 ` Rich Felker
2014-10-07 16:08 ` David Daney
2014-10-07 18:16 ` Andy Lutomirski
2014-10-07 23:20 ` Ralf Baechle
2014-10-07 23:59 ` David Daney
2014-10-08 0:18 ` Chuck Ebbert
2014-10-08 2:37 ` Rich Felker
2014-10-08 10:31 ` Paul Burton
2014-10-07 1:02 ` Kevin D. Kissell
2014-10-07 1:38 ` Rich Felker
2014-10-07 4:32 ` David Daney
2014-10-07 11:53 ` James Hogan
2014-10-07 12:22 ` James Hogan
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=20141006205459.GZ23797@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.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
all inboxes | Powered by JetHome®