linux-mips
[Top] [All Lists]

Re: [PATCH 1/2] MIPS: Preliminary vdso.

To: "Kevin D. Kissell" <kevink@paralogos.com>
Subject: Re: [PATCH 1/2] MIPS: Preliminary vdso.
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 22 Apr 2009 11:01:44 -0700
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <49EEE4EA.8040100@paralogos.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <49EE3B0F.3040506@caviumnetworks.com> <1240349605-1921-1-git-send-email-ddaney@caviumnetworks.com> <49EEE4EA.8040100@paralogos.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Kevin D. Kissell wrote:
David Daney wrote:
This is a preliminary patch to add a vdso to all user processes.
Still missing are ELF headers and .eh_frame information.  But it is
enough to allow us to move signal trampolines off of the stack.

We allocate a single page (the vdso) and write all possible signal
trampolines into it.  The stack is moved down by one page and the vdso
is mapped into this space.

Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Note that for FPU-less CPUs, the kernel FP emulator also uses a user
stack trampoline to execute instructions in the delay slots of emulated
FP branches.  I didn't see any of the math-emu modules being tweaked in
either part of your patch.  Presumably, one would want to move that
operation into the vdso as well.  With the proposed patch, I'm not sure
whether things would continue working normally as before, still using
the user stack, or whether the dsemulret code depends on something that
is changed by the patch, and will now implode.  Probably the former, but
paranoia is not a character defect in OS kernel work. I don't have a
test case handy (nor a test system any more), but compiling something
like whetstone or linpack in C with a high degree of optimization will
*probably* generate FP branches with live delay slots.


It is an ugly problem.  I am trying to hack something up to fix it.

David Daney

<Prev in Thread] Current Thread [Next in Thread>