linux-um archives
 help / color / mirror / Atom feed
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);
}

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox