From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
To: Jeff Dike <jdike@addtoit.com>
Cc: user-mode-linux-devel@lists.sourceforge.net, Carl <lists@outervoid.net>
Subject: Re: [uml-devel] Memory corruption/errors?
Date: Wed, 22 Dec 2004 23:07:33 +0100 [thread overview]
Message-ID: <41C9F025.60208@fujitsu-siemens.com> (raw)
In-Reply-To: <41C9EF67.1030407@fujitsu-siemens.com>
[-- Attachment #1: Type: text/plain, Size: 5612 bytes --]
Bodo Stroesser wrote:
> Carl wrote:
>
>> Hi,
>>
>> Running the piece of code from the URL below is generating errors on
>> various UML kernels:
>>
>> http://downloads.rimuhosting.com/memtest.c
>>
>> Kernels tested are: 2.4.27, 2.4.27-bs1, 2.6.9-bb4.
>>
Sorry for forgetting to attach the testtool.
Here it is.
Bodo
>> Different UML host servers have been tried too, and only UMLs running on
>> SMP (dual Xeon) servers seem to have the problem (P4s with HT are fine).
>>
>> Can anyone else reproduce the errors? Any ideas?
>>
>> Thanks, Carl
>
>
> After having found a bug in SKAS-signal-handling, I modified memtest.c to
> trigger that bug (attached: memtest2.c). This probably is the same problem,
> Carl saw. If so, Carl's problem shouldn't happen in TT-mode.
>
>
> That's the problem:
>
> In SKAS userspace(), when the kernel is entered, all regs including fpregs
> are saved by save_registers() to skas_regs and restored on exit by
> restore_registers() from skas_regs.
> If an signal handler has to be started, the original fpstate is saved in
> the
> sigcontext and must be restored, when sys_sigreturn is called.
> When the kernel is entered for sys_sigreturn on return from the signal
> handler,
> the fpregs again are saved with save_registers(). Thus skas_regs hold the
> fpstate from the end of the signal handler.
> Now copy_sc_from_user_skas() tries to restore the original state. But the
> fpstate from the sigcontext isn't written to skas_regs, but directly to the
> fp-registers of the userspace process with set_fpregs().
> When exit from kernel is done after that, restore_registers() overwrites
> the fp-registers of the userspace-process with the fpstate from skas_regs,
> which is the wrong one that comes from the signal handler!
>
> There is another problem in UML-signal-handling, that makes the problem
> very
> hard to reproduce:
> Normally, on sighandler-entry, the fpu-registers should be cleared. But UML
> doesn't clear the fpu. So, the original values in the fpu-registers stay
> alive, if the signal-handler doesn't push to many new values. In most
> cases, even if the sighandler uses the fpu, only the compare-result-flags
> have changed after return from sighandler. If fp-values have to be
> compared,
> AFAICS an fp-compare-instruction is used, followed immediately by a move
> of the compare-result-flags to the ax-register. So, only a sighandler
> hitting exactly between those two instructions, will hurt in most cases!
>
>
> Solution:
>
> I started to do a patch, but stopped, since it will need a big patch to
> make this area clean (and I will be offline for about 2 weeks ...):
>
> 1) In SKAS, copy_sc_from_user_skas() should build the _fpstate in
> sigcontext from skas_regs, not from new values read in by get_fpregs().
> The current code even lacks writing i387_fsave_struct.status containing
> the magic which flags the _fpstate format.
> The "format" of the written _fpstate should depend on
> have_fpx_regs. This means, convert_fxsr_to_user_tt() should be
> modified and made generally available to help cover the case of
> (have_fpx_regs == 1), where skas_regs don't contain fsave, but
> fxsave only.
> 2) When having created a sigcontext, UML should clear the fpregs in
> skas_regs resp. tt_regs.sc->_fpstate, to make the sighandler see
> a cleared fpu.
> 3) copy_sc_from_user_skas() should copy the _fpstate from sigcontext
> to skas_regs. To handle the different formats of the _fpstate,
> convert_fxsr_from_user_tt() should be modified and made available.
> copy_sc_from_user_skas() should check sigcontext->_fpstate. If
> this is NULL, skas_regs.fp/fpx should be cleared. (SKAS doesn't
> write that NULL, but on the host or in TT, the kernel sometimes
> writes it. So, I would like to have SKAS tolerate a NULL here
> instead of segfaulting).
> 4) set_fpregs, get_fpregs, set_fpxregs, get_fpxregs currently support
> TT-mode only. set_fpxregs and get_fpxregs should return -EIO, if
> (!have_fpx_regs). Therefore, the check for availability of
> PTRACE_GET_FPXREGS should be done in SKAS and TT, and have_fpx_regs
> should be available in both modes.
> 5) get_fpregs in TT mode simply should copy the first (fp-reg) part of
> tt_regs.sc->fpstatus to user without converting. This part of fpstate
> always is written correctly by the host kernel. Also set_fpregs has to
> copy that part from user. If (have_fpx_regs == 1) the fpx-parts of
> fpstatus should be reconstructed from that, to have them available for
> the next possible get_fpxregs.
> 6) get_fpxregs and set_fpxregs in TT for (have_fpx_regs == 1) may work
> immediately with the fpx-part of tt_regs.sc->fpstatus, but set_fpxregs
> also has to write the fp-part accordingly.
> 7) get_fpregs, set_fpregs, get_fpxregs and set_fpxregs should support SKAS.
> This could be done by simply ripping code or method from i386.
> SKAS holds the data needed in skas_regs.fp or skas_regs.fpx
>
> I hope, this helps a bit. Sorry for not having the time to do the patch
> by myself.
>
> Bodo
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
[-- Attachment #2: memtest2.c --]
[-- Type: text/plain, Size: 1138 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <sys/time.h>
#define N (20*1024)
void sighdlr(int sig)
{
double a;
a = 256;
double observed = a;
double expected = 257;
if ( observed == expected )
printf("Error in sighdlr()\n");
}
int
main (void)
{
size_t i, k;
struct itimerval itimer = { { 0, 10000}, { 0, 10000} };
signal(SIGALRM, sighdlr);
setitimer( ITIMER_REAL, &itimer, NULL);
for (k = 1; k < 1000; k++) {
double *a = malloc (N * sizeof (double));
if (a == 0) {
printf ("malloc failed at k=%u\n", k);
exit (1);
}
for (i = 0; i < N; i++) {
a[i] = (double) i;
double observed = a[i];
double expected = (double) i;
if (observed != expected) {
printf ("failed at i=%u, k=%u (obs %.18g vs exp %.18g)\n", i, k,
observed, expected);
}
}
for (i = 0; i < N; i++) {
double observed = a[i];
double expected = (double) i;
if (observed != expected) {
printf ("failed at i=%u, k=%u (obs %.18g vs exp %.18g)\n", i, k,
observed, expected);
// exit (1);
}
}
free (a);
}
exit (0);
}
next prev parent reply other threads:[~2004-12-22 22:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-20 22:56 [uml-devel] Memory corruption/errors? Carl
2004-12-22 12:09 ` Bodo Stroesser
2004-12-22 19:58 ` Peter
2004-12-22 21:33 ` Bodo Stroesser
2004-12-22 23:04 ` Peter
2004-12-22 23:15 ` Bodo Stroesser
2004-12-22 22:04 ` Bodo Stroesser
2004-12-22 22:07 ` Bodo Stroesser [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-12-23 13:26 [Fwd: Re: [uml-devel] Memory corruption/errors?] Bodo Stroesser
2004-12-24 2:32 ` Peter
2005-01-10 4:21 ` [uml-devel] Memory corruption/errors? peter
2005-01-10 10:10 ` Bodo Stroesser
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=41C9F025.60208@fujitsu-siemens.com \
--to=bstroesser@fujitsu-siemens.com \
--cc=jdike@addtoit.com \
--cc=lists@outervoid.net \
--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.