From: Eli Cooper <elicooper@gmx.com>
To: Richard Weinberger <richard@nod.at>,
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 21:56:52 +0800 [thread overview]
Message-ID: <56E571A4.7070702@gmx.com> (raw)
In-Reply-To: <56E51D98.7010700@nod.at>
Hi Richard,
On 2016/3/13 15:58, Richard Weinberger wrote:
> 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.
Actually only two functions' stack frame size exceed kernel's default
warning threshold (1024 bytes) after the _xstate extension, i.e.,
copy_sc_from_user and copy_sc_to_user. That's because they have an
_xstate on stack as well as a sigcontext, which contains another
_xstate. Context switches due to signal handling are rare; thus I think
having a kmalloc() for signal handling is acceptable.
>>> >> 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.
No, it seems that this issue does not depend on the host kernel, UML
kernel, or CPU. I can reproduce this bug on a variety of combinations of
them, with the host kernel ranging from 2.6.32 to 3.19 to 4.5.
Thanks,
Eli
>
> Thanks,
> //richard
>
------------------------------------------------------------------------------
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 13:55 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
2016-03-13 13:56 ` Eli Cooper [this message]
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=56E571A4.7070702@gmx.com \
--to=elicooper@gmx.com \
--cc=jdike@addtoit.com \
--cc=richard@nod.at \
--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.