From: Richard Weinberger <richard@nod.at>
To: Eli Cooper <elicooper@gmx.com>,
user-mode-linux-devel@lists.sourceforge.net
Cc: Jeff Dike <jdike@addtoit.com>
Subject: Re: [uml-devel] [PATCH 1/3] um: extend _fpstate to _xstate
Date: Sun, 13 Mar 2016 08:58:16 +0100 [thread overview]
Message-ID: <56E51D98.7010700@nod.at> (raw)
In-Reply-To: <56E3C055.1080301@gmx.com>
Eli,
Am 12.03.2016 um 08:08 schrieb Eli Cooper:
> Hi Richard,
>
> On 2016/3/10 4:44, Richard Weinberger wrote:
>> Hmm, this needs rework. Having everything on the stack is not good.
>
> Okay, I'll rework the functions whose stack size is greater than the
> warning threshold by using kmalloc.
I fear it is not that easy. Having a kmalloc() per context switch would
be every expensive. Even for UML.
>> Can you also create a selftest such that this bug cannot happen again?
>
> It seems that instead of writing a self-test showing this problem cannot
> happen again, I wrote a test that manifested another bug that is not
> directly related to my patch.
>
> Without applying my patch, the current UML should support XMM registers
> because those are covered by _fpstate and PTRACE_GETFPREGS. But it
> seemed that XMM registers are not restored after the signal handler returns.
>
> In the following quick test, the main loop should run indefinitely
> despite XMM registers are modified by the signal handler. But in UML,
> the loop breaks randomly within a minute or two, showing that the
> registers are corrupted. So far I haven't found the cause. Any hints?
Meh. :(
Can you figure out whether the issue depends on the host kernel? i.e. try something older
and Linus' tree.
UML is a heavy user of ptrace(), maybe the recent FPU cleanup on x86 broke something.
Thanks,
//richard
> Thanks,
> Eli
>
> ---
> /* test if signal handling preserves XMM registers */
> #include <stdio.h>
> #include <unistd.h>
> #include <signal.h>
>
> int count;
>
> void sighandler(int signum)
> {
> count++;
>
> /* alarm(1) without calling libc */
> asm("mov $0x1,%rdi");
> asm("mov $0x25,%rax");
> asm("syscall");
>
> asm("movq $0xdeadbeef,%r11");
> /* the following two instructions
> * modify xmm0 and xmm1 registers */
> asm("vmovq %r11,%xmm0");
> asm("vmovq %r11,%xmm1");
> }
>
> int main()
> {
> struct sigaction act;
> double a = 3.14159, b = 2.71828;
>
> act.sa_handler = sighandler;
> act.sa_flags = 0;
> sigemptyset(&act.sa_mask);
> sigaction(SIGALRM, &act, NULL);
>
> alarm(1);
>
> /* this loop should run indefinitely */
> while (a + b == a + b) ;
>
> printf("count = %d\n", count);
> return 1;
> }
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2016-03-13 7:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-06 14:36 [uml-devel] [PATCH 0/3] um: Add support for extended processor state Eli Cooper
2016-03-06 14:36 ` [uml-devel] [PATCH 1/3] um: extend _fpstate to _xstate Eli Cooper
2016-03-09 20:44 ` Richard Weinberger
2016-03-12 7:08 ` Eli Cooper
2016-03-13 7:58 ` Richard Weinberger [this message]
2016-03-13 13:56 ` Eli Cooper
2016-03-14 7:58 ` stian
2016-03-06 14:36 ` [uml-devel] [PATCH 2/3] um: add extended processor state save/restore support Eli Cooper
2016-03-06 14:36 ` [uml-devel] [PATCH 3/3] um: fix ptrace PTRACE_GETFPREGS and PTRACE_SETFPREG support Eli Cooper
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=56E51D98.7010700@nod.at \
--to=richard@nod.at \
--cc=elicooper@gmx.com \
--cc=jdike@addtoit.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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 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.