[uml-devel] Memory corruption/errors?

[uml-devel] Memory corruption/errors?

[Carl]

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.

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



-------------------------------------------------------
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

Re: [uml-devel] Memory corruption/errors?

[Bodo Stroesser]

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.
> 
> 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
> 
> 
> 
> -------------------------------------------------------
> 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
Do you see messages like this one

     "failed at i=17240, k=85 (obs 17240 vs exp 17240)"

with obs and exp being equal?

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

Re: [uml-devel] Memory corruption/errors?

[Peter]

I don't recall seeing an error where the obs and exp were equal.  I saw 
plenty where they were not equal.

The code is pretty simple:
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);
};

Maybe it is just some unexpected handling on the != operator with doubles?

Are you seeing cases where obs!=exp?  And difference if you run it on a 
uni-proc server vs. a smp server?

Regards, Peter

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.
>>
>> 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
Do you see messages like this one

     "failed at i=17240, k=85 (obs 17240 vs exp 17240)"

with obs and exp being equal?


-------------------------------------------------------
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

Re: [uml-devel] Memory corruption/errors?

[Bodo Stroesser]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

Peter wrote:
> I don't recall seeing an error where the obs and exp were equal.  I saw 
> plenty where they were not equal.
> 
> The code is pretty simple:
> 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);
> };
> 
> Maybe it is just some unexpected handling on the != operator with doubles?
> 
> Are you seeing cases where obs!=exp?  And difference if you run it on a 
> uni-proc server vs. a smp server?
No. I just found a problem in SKAS sigcontext handling.
The fp-registers are not restored correctly. Then, I remembered the problems
with memtest, which uses floatpoint.
I modified the test to have sighandlers being started evey 10ms, using
the fpu in the sighandler. Then, *many* error occured in my "memtest2".
Without the modification, I couldn't reproduce the problems.

Two questions:
1) are you able to reproduce the problems in TT-mode?
2) do you have any idea, why a signal handler using floatpoint should be started,
    while running the original memtest?

Have attached my memtest2.c

Regards
Bodo

P.S.: Mail with full description of the problem I've found will follow soon.
> 
> Regards, Peter
> 
> 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.
>>>
>>> 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
> 
> Do you see messages like this one
> 
>     "failed at i=17240, k=85 (obs 17240 vs exp 17240)"
> 
> with obs and exp being equal?


[-- 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);
}

Re: [uml-devel] Memory corruption/errors?

[Bodo Stroesser]

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.
> 
> 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

Re: [uml-devel] Memory corruption/errors?

[Bodo Stroesser]

[-- 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);
}

Re: [uml-devel] Memory corruption/errors?

[Peter]

I don't run TT mode UMLs.  So, no I haven't tried that.

I don't know about the sighandler.  The program runs as it was listed. 
It is running on a 'regular' server (Debian, and/or WBL3) with other 
processes running.  And the host servers happen to be running other 
UMLs.  I don't know if that information helps.  (i.e. can a sighandler 
in another process on the UML or on the host cause this problem?)

I'd be happy to try out a skas patch - preferably if it just applied to 
the guest ;)  To see if it fixes things or not.

Regards, Peter


Bodo Stroesser wrote:
> Peter wrote:
> 
>> I don't recall seeing an error where the obs and exp were equal.  I 
>> saw plenty where they were not equal.
>>
>> The code is pretty simple:
>> 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);
>> };
>>
>> Maybe it is just some unexpected handling on the != operator with 
>> doubles?
>>
>> Are you seeing cases where obs!=exp?  And difference if you run it on 
>> a uni-proc server vs. a smp server?
> 
> No. I just found a problem in SKAS sigcontext handling.
> The fp-registers are not restored correctly. Then, I remembered the 
> problems
> with memtest, which uses floatpoint.
> I modified the test to have sighandlers being started evey 10ms, using
> the fpu in the sighandler. Then, *many* error occured in my "memtest2".
> Without the modification, I couldn't reproduce the problems.
> 
> Two questions:
> 1) are you able to reproduce the problems in TT-mode?
> 2) do you have any idea, why a signal handler using floatpoint should be 
> started,
>    while running the original memtest?
> 
> Have attached my memtest2.c
> 
> Regards
> Bodo
> 
> P.S.: Mail with full description of the problem I've found will follow 
> soon.
> 
>>
>> Regards, Peter
>>
>> 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.
>>>>
>>>> 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
>>
>>
>> Do you see messages like this one
>>
>>     "failed at i=17240, k=85 (obs 17240 vs exp 17240)"
>>
>> with obs and exp being equal?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> #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);
> }


-------------------------------------------------------
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

Re: [uml-devel] Memory corruption/errors?

[Bodo Stroesser]

Peter wrote:
> I don't run TT mode UMLs.  So, no I haven't tried that.
> 
> I don't know about the sighandler.  The program runs as it was listed. 
> It is running on a 'regular' server (Debian, and/or WBL3) with other 
> processes running.  And the host servers happen to be running other 
> UMLs.  I don't know if that information helps.  (i.e. can a sighandler 
> in another process on the UML or on the host cause this problem?)
> 
> I'd be happy to try out a skas patch - preferably if it just applied to 
> the guest ;)  To see if it fixes things or not.
> 
> Regards, Peter
> 
I could try to create a patch, just for testing.
What machine is your host? It probably has fxsr?

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

Re: [uml-devel] Memory corruption/errors?

[peter]

Bodo?

Peter wrote:
> Hi.  Thanks for the patch.
> 
> I am trying to apply these against 2.6.9 + bb4 (from 
> http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.9-bb4/). 
>   Your patch is not applying (no such file, HUNKs failing, etc).
> 
> Do you have a version of your patch that compiles against 2.6.9-bb4? 
> Ideally I'd like to get this working with 2.6.9-bb4 since that seems to 
> be the 'stable' 2.6 UML guest kernel.
> 
> Else, can you let me know what code (links to all component patches 
> appreciated) your patch is against and I will try that.
> 
> Regards, Peter
> 
> Bodo Stroesser wrote:
> 
>> I'm forwarding this to the list, because I did a "Reply to all"
>> missing the fact, that the list wasn't CC'ed
>>
>> Bodo
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: [uml-devel] Memory corruption/errors?
>> From:
>> Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>> Date:
>> Thu, 23 Dec 2004 13:58:18 +0100
>> To:
>> Peter <peter.spamcatcher@rimuhosting.com>
>>
>> To:
>> Peter <peter.spamcatcher@rimuhosting.com>
>> CC:
>> Jeff Dike <jdike@addtoit.com>
>>
>>
>> Peter wrote:
>>
>>>
>>> I really don't know what fxsr is.  But I think I have it.  My servers 
>>> are dual proc xeons.  2.6.8.1 with skas3 v7 (mostly).
>>>
>>> # cat /proc/cpuinfo  | grep fxsr
>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>> pbe cid
>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>> pbe cid
>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>> pbe cid
>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>> pbe cid
>>
>>
>> Yes. Here the machine tell us, that fxsr is available.
>>
>>>
>>> So you can only reproduce the problem when your use the sighandler?  
>>> But when you use your patch the problem is not triggered (even with 
>>> the sighandler)?
>>>
>>> I'd be happy to try a patch.  I only have production machines at the 
>>> moment, so I may not be able to restart one for a week or two until 
>>> some new ones arrive.
>>>
>>> Regards, Peter
>>>
>>> Bodo Stroesser wrote:
>>>
>>>> Peter wrote:
>>>>
>>>>> I don't run TT mode UMLs.  So, no I haven't tried that.
>>>>>
>>>>> I don't know about the sighandler.  The program runs as it was 
>>>>> listed. It is running on a 'regular' server (Debian, and/or WBL3) 
>>>>> with other processes running.  And the host servers happen to be 
>>>>> running other UMLs.  I don't know if that information helps.  (i.e. 
>>>>> can a sighandler in another process on the UML or on the host cause 
>>>>> this problem?)
>>>>>
>>>>> I'd be happy to try out a skas patch - preferably if it just 
>>>>> applied to the guest ;)  To see if it fixes things or not.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>> I could try to create a patch, just for testing.
>>>> What machine is your host? It probably has fxsr?
>>>>
>>>> Bodo
>>
>>
>> OK. Here it is! For testing only!
>>
>> I've tested the patch on a XEON 2.4GHz, and AFAICS it works.
>> But no guarantee!
>>
>> The errors with memtest2 no longer occur on my system.
>>
>> I have no machine without fxsr, thus I couldn't test that.
>> When the patch is applied, don't forget to do
>>     "make clean ARCH=um"
>> before recompiling the kernel.Else you will get an
>> inconsitent kernel that crashes.
>>
>> Bodo
>>
>>
>> ------------------------------------------------------------------------
>>
>> From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>>
>> This patch is for testing only!
>>
>> It's a quick and dirty patch to verify, that wrong fp-context
>> saving and restore really are the cause of errors in "memtest.c"
>> It fixes the problem by:
>>  - making have_fpx_regs accessible for other modules instead of
>>    declaring it "static" in arch/um/os-Linux/sys-i386/registers.c
>>  - Adding 1 to HOST_FP_SIZE to have room for the "status" (and magic)
>>    field. Now skas.fp + skas.xfp combined have the size of
>>    struct _fpstatus
>>  - in arch/um/sys-i386/signal.c adding some code, that handles
>>    the _fpstatus in sigcontext differently, depending on have_fpx_regs.
>>    For (have_fpx_regs == 0), the _fpstatus simply is copied to/from
>>    user from/to skas.fp. When writing to user, the status field is
>>    created also.
>>    For (have_fpx_regs == 1), when writing to user, the full _fpstatus
>>    is created in skas.fp and skas.xfp, from the data found in skas.xfp.
>>    Then it is copied to user. When reading, the full _fpstatus is read
>>    to skas.fp and skas.xfp. Then, skas.xfp is reconstructed from this
>>    data.
>>
>> ---
>>
>> --- arch/um/os-Linux/sys-i386/registers.c.orig    2004-12-23 
>> 00:22:54.000000000 +0100
>> +++ arch/um/os-Linux/sys-i386/registers.c    2004-12-23 
>> 00:23:13.016000444 +0100
>> @@ -17,7 +17,7 @@
>>  static unsigned long exec_regs[HOST_FRAME_SIZE];
>>  static unsigned long exec_fp_regs[HOST_FP_SIZE];
>>  static unsigned long exec_fpx_regs[HOST_XFP_SIZE];
>> -static int have_fpx_regs = 1;
>> +int have_fpx_regs = 1;
>>  
>>  void init_thread_registers(union uml_pt_regs *to)
>>  {
>> --- arch/um/sys-i386/signal.c.orig    2004-12-23 00:17:19.000000000 +0100
>> +++ arch/um/sys-i386/signal.c    2004-12-23 11:41:41.928379633 +0100
>> @@ -19,15 +19,37 @@
>>  
>>  #include "skas.h"
>>  
>> +
>> +static inline unsigned short twd_i387_to_fxsr( unsigned short twd )
>> +{
>> +    unsigned int tmp; /* to avoid 16 bit prefixes in the code */
>> +
>> +    /* Transform each pair of bits into 01 (valid) or 00 (empty) */
>> +    tmp = ~twd;
>> +    tmp = (tmp | (tmp>>1)) & 0x5555; /* 0V0V0V0V0V0V0V0V */
>> +    /* and move the valid bits to the lower byte. */
>> +    tmp = (tmp | (tmp >> 1)) & 0x3333; /* 00VV00VV00VV00VV */
>> +    tmp = (tmp | (tmp >> 2)) & 0x0f0f; /* 0000VVVV0000VVVV */
>> +    tmp = (tmp | (tmp >> 4)) & 0x00ff; /* 00000000VVVVVVVV */
>> +    return tmp;
>> +}
>> +
>> +#define printk printf
>> +
>>  static int copy_sc_from_user_skas(struct pt_regs *regs,
>>                    struct sigcontext *from)
>>  {
>>        struct sigcontext sc;
>> -    unsigned long fpregs[HOST_FP_SIZE];
>> -    int err;
>> +    struct _fpstate * fp = (struct _fpstate *)regs->regs.skas.fp;
>> +    int size, err, i;
>> +
>> +    if (have_fpx_regs)
>> +        size = sizeof(struct _fpstate);
>> +    else
>> +        size = sizeof(regs->regs.skas.fp);
>>  
>>      err = copy_from_user(&sc, from, sizeof(sc));
>> -    err |= copy_from_user(fpregs, sc.fpstate, sizeof(fpregs));
>> +    err |= copy_from_user(fp, sc.fpstate, size);
>>      if(err)
>>          return(err);
>>  
>> @@ -48,23 +70,70 @@
>>      REGS_EFLAGS(regs->regs.skas.regs) = sc.eflags;
>>      REGS_SS(regs->regs.skas.regs) = sc.ss;
>>  
>> -    err = ptrace_setfpregs(userspace_pid[0], fpregs);
>> -    if(err < 0){
>> -          printk("copy_sc_from_user_skas - PTRACE_SETFPREGS failed, "
>> -               "errno = %d\n", err);
>> -        return(1);
>> +    if (have_fpx_regs) {
>> +        *(unsigned short *)fp->_fxsr_env = (unsigned short)(fp->cw & 
>> 0xffff);
>> +        *((unsigned short *)fp->_fxsr_env + 1) = (unsigned 
>> short)(fp->sw & 0xffff);
>> +        *((unsigned short *)fp->_fxsr_env + 2) = 
>> twd_i387_to_fxsr(fp->tag & 0xffff);
>> +        *((unsigned short *)fp->_fxsr_env + 3) = (unsigned 
>> short)(fp->cssel >> 16);
>> +        fp->_fxsr_env[2] = fp->ipoff;
>> +        fp->_fxsr_env[3] = fp->cssel & 0xffff;
>> +        fp->_fxsr_env[4] = fp->dataoff;
>> +        fp->_fxsr_env[5] = fp->datasel;
>> +        for ( i=0; i<8; i++)
>> +        memcpy(fp->_fxsr_st+i, fp->_st+i, sizeof(struct _fpreg));
>>      }
>>  
>>      return(0);
>>  }
>>  
>> +static inline unsigned long twd_fxsr_to_i387( struct _fpstate *fp)
>> +{
>> +    struct _fpxreg *st = fp->_fxsr_st;
>> +    unsigned long twd = fp->_fxsr_env[1] & 0x0000fffflu;
>> +    unsigned long tag;
>> +    unsigned long ret = 0xffff0000lu;
>> +    int i;
>> +
>> +    for ( i = 0 ; i < 8 ; i++, st++ ) {
>> +    if ( twd & 0x1 ) {
>> +        switch ( st->exponent & 0x7fff ) {
>> +        case 0x7fff:
>> +            tag = 2;
>> +            break;
>> +        case 0x0000:
>> +            if ( !st->significand[0] &&
>> +                 !st->significand[1] &&
>> +                 !st->significand[2] &&
>> +                 !st->significand[3] ) {
>> +            tag = 1;
>> +            } else {
>> +            tag = 2;
>> +            }
>> +            break;
>> +        default:
>> +            if ( st->significand[3] & 0x8000 ) {
>> +            tag = 0;
>> +            } else {
>> +            tag = 2;
>> +            }
>> +            break;
>> +        }
>> +    } else {
>> +        tag = 3;
>> +    }
>> +    ret |= (tag << (2 * i));
>> +    twd = twd >> 1;
>> +    }
>> +    return ret;
>> +}
>> +
>>  int copy_sc_to_user_skas(struct sigcontext *to, struct _fpstate *to_fp,
>>               struct pt_regs *regs)
>>  {
>>        struct sigcontext sc;
>> -    unsigned long fpregs[HOST_FP_SIZE];
>> +    struct _fpstate * fp = (struct _fpstate *)regs->regs.skas.fp;
>>      struct faultinfo * fi = &current->thread.arch.faultinfo;
>> -    int err;
>> +    int size, i;
>>  
>>      sc.gs = REGS_GS(regs->regs.skas.regs);
>>      sc.fs = REGS_FS(regs->regs.skas.regs);
>> @@ -87,20 +156,30 @@
>>      sc.err = fi->error_code;
>>      sc.trapno = fi->trap_no;
>>  
>> -    err = ptrace_getfpregs(userspace_pid[0], fpregs);
>> -    if(err < 0){
>> -          printk("copy_sc_to_user_skas - PTRACE_GETFPREGS failed, "
>> -               "errno = %d\n", err);
>> -        return(1);
>> +    if (have_fpx_regs) {
>> +        fp->cw = (unsigned long)*(unsigned short *)fp->_fxsr_env | 
>> 0xffff0000ul;
>> +        fp->sw = (unsigned long)*((unsigned short *)fp->_fxsr_env+1) 
>> | 0xffff0000ul;
>> +        fp->tag = twd_fxsr_to_i387(fp);
>> +        fp->ipoff = fp->_fxsr_env[2];
>> +        fp->cssel = fp->_fxsr_env[3] |
>> +            ((unsigned long)*((unsigned short *)fp->_fxsr_env+3) << 16);
>> +        fp->dataoff = fp->_fxsr_env[4];
>> +        fp->datasel = fp->_fxsr_env[5];
>> +        fp->status = (unsigned short)(fp->sw & 0xfffful);
>> +        fp->magic = 0;
>> +        for ( i=0; i<8; i++)
>> +        memcpy(fp->_st+i, fp->_fxsr_st+i, sizeof(struct _fpreg));
>> +        size = sizeof(struct _fpstate);
>> +    }
>> +    else {
>> +        *(unsigned long *)&fp->status = fp->sw;
>> +        size = sizeof(regs->regs.skas.fp);
>>      }
>>      to_fp = (to_fp ? to_fp : (struct _fpstate *) (to + 1));
>>      sc.fpstate = to_fp;
>>  
>> -    if(err)
>> -          return(err);
>> -
>>      return(copy_to_user(to, &sc, sizeof(sc)) ||
>> -           copy_to_user(to_fp, fpregs, sizeof(fpregs)));
>> +           copy_to_user(to_fp, fp, size));
>>  }
>>  #endif
>>  
>> --- arch/um/kernel/skas/util/mk_ptregs-i386.c.orig    2004-12-23 
>> 10:46:41.143243494 +0100
>> +++ arch/um/kernel/skas/util/mk_ptregs-i386.c    2004-12-23 
>> 11:08:01.272251951 +0100
>> @@ -13,8 +13,9 @@
>>      printf("#define __SKAS_PT_REGS_\n");
>>      printf("\n");
>>      printf("#define HOST_FRAME_SIZE %d\n", FRAME_SIZE);
>> +    /* This needs to have space for "status", too */
>>      printf("#define HOST_FP_SIZE %d\n", -           sizeof(struct 
>> user_i387_struct) / sizeof(unsigned long));
>> +           sizeof(struct user_i387_struct) / sizeof(unsigned long) + 1);
>>      printf("#define HOST_XFP_SIZE %d\n",             sizeof(struct 
>> user_fxsr_struct) / sizeof(unsigned long));
>>  
> 
> 
> 
> -------------------------------------------------------
> 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


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Memory corruption/errors?

[Bodo Stroesser]

peter wrote:
> Bodo?
Hi Peter,

sorry, have been off the net for a while.
The patch *really* was quick and dirty (Was in a hurry cause I wanted to send
it before my Xmas holidays). I even forgot to make it apply with "patch -p1"!
Thus, it must be inserted with "patch -p0", then it should apply.

Sorry for that.

By the way: the patch was created against 2.6.10-rc3-mm1 + Jeff's incrementals,
which was the latest version at that time. But I guess, the patch should apply
to 2.6.9-bb4, too.

Bodo


> 
> Peter wrote:
> 
>> Hi.  Thanks for the patch.
>>
>> I am trying to apply these against 2.6.9 + bb4 (from 
>> http://www.user-mode-linux.org/~blaisorblade/patches/guest/uml-2.6.9-bb4/). 
>>   Your patch is not applying (no such file, HUNKs failing, etc).
>>
>> Do you have a version of your patch that compiles against 2.6.9-bb4? 
>> Ideally I'd like to get this working with 2.6.9-bb4 since that seems 
>> to be the 'stable' 2.6 UML guest kernel.
>>
>> Else, can you let me know what code (links to all component patches 
>> appreciated) your patch is against and I will try that.
>>
>> Regards, Peter
>>
>> Bodo Stroesser wrote:
>>
>>> I'm forwarding this to the list, because I did a "Reply to all"
>>> missing the fact, that the list wasn't CC'ed
>>>
>>> Bodo
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Subject:
>>> Re: [uml-devel] Memory corruption/errors?
>>> From:
>>> Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>>> Date:
>>> Thu, 23 Dec 2004 13:58:18 +0100
>>> To:
>>> Peter <peter.spamcatcher@rimuhosting.com>
>>>
>>> To:
>>> Peter <peter.spamcatcher@rimuhosting.com>
>>> CC:
>>> Jeff Dike <jdike@addtoit.com>
>>>
>>>
>>> Peter wrote:
>>>
>>>>
>>>> I really don't know what fxsr is.  But I think I have it.  My 
>>>> servers are dual proc xeons.  2.6.8.1 with skas3 v7 (mostly).
>>>>
>>>> # cat /proc/cpuinfo  | grep fxsr
>>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>>> pbe cid
>>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>>> pbe cid
>>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>>> pbe cid
>>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr 
>>>> pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
>>>> pbe cid
>>>
>>>
>>>
>>> Yes. Here the machine tell us, that fxsr is available.
>>>
>>>>
>>>> So you can only reproduce the problem when your use the sighandler?  
>>>> But when you use your patch the problem is not triggered (even with 
>>>> the sighandler)?
>>>>
>>>> I'd be happy to try a patch.  I only have production machines at the 
>>>> moment, so I may not be able to restart one for a week or two until 
>>>> some new ones arrive.
>>>>
>>>> Regards, Peter
>>>>
>>>> Bodo Stroesser wrote:
>>>>
>>>>> Peter wrote:
>>>>>
>>>>>> I don't run TT mode UMLs.  So, no I haven't tried that.
>>>>>>
>>>>>> I don't know about the sighandler.  The program runs as it was 
>>>>>> listed. It is running on a 'regular' server (Debian, and/or WBL3) 
>>>>>> with other processes running.  And the host servers happen to be 
>>>>>> running other UMLs.  I don't know if that information helps.  
>>>>>> (i.e. can a sighandler in another process on the UML or on the 
>>>>>> host cause this problem?)
>>>>>>
>>>>>> I'd be happy to try out a skas patch - preferably if it just 
>>>>>> applied to the guest ;)  To see if it fixes things or not.
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>> I could try to create a patch, just for testing.
>>>>> What machine is your host? It probably has fxsr?
>>>>>
>>>>> Bodo
>>>
>>>
>>>
>>> OK. Here it is! For testing only!
>>>
>>> I've tested the patch on a XEON 2.4GHz, and AFAICS it works.
>>> But no guarantee!
>>>
>>> The errors with memtest2 no longer occur on my system.
>>>
>>> I have no machine without fxsr, thus I couldn't test that.
>>> When the patch is applied, don't forget to do
>>>     "make clean ARCH=um"
>>> before recompiling the kernel.Else you will get an
>>> inconsitent kernel that crashes.
>>>
>>> Bodo
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>>>
>>> This patch is for testing only!
>>>
>>> It's a quick and dirty patch to verify, that wrong fp-context
>>> saving and restore really are the cause of errors in "memtest.c"
>>> It fixes the problem by:
>>>  - making have_fpx_regs accessible for other modules instead of
>>>    declaring it "static" in arch/um/os-Linux/sys-i386/registers.c
>>>  - Adding 1 to HOST_FP_SIZE to have room for the "status" (and magic)
>>>    field. Now skas.fp + skas.xfp combined have the size of
>>>    struct _fpstatus
>>>  - in arch/um/sys-i386/signal.c adding some code, that handles
>>>    the _fpstatus in sigcontext differently, depending on have_fpx_regs.
>>>    For (have_fpx_regs == 0), the _fpstatus simply is copied to/from
>>>    user from/to skas.fp. When writing to user, the status field is
>>>    created also.
>>>    For (have_fpx_regs == 1), when writing to user, the full _fpstatus
>>>    is created in skas.fp and skas.xfp, from the data found in skas.xfp.
>>>    Then it is copied to user. When reading, the full _fpstatus is read
>>>    to skas.fp and skas.xfp. Then, skas.xfp is reconstructed from this
>>>    data.
>>>
>>> ---
>>>
>>> --- arch/um/os-Linux/sys-i386/registers.c.orig    2004-12-23 
>>> 00:22:54.000000000 +0100
>>> +++ arch/um/os-Linux/sys-i386/registers.c    2004-12-23 
>>> 00:23:13.016000444 +0100
>>> @@ -17,7 +17,7 @@
>>>  static unsigned long exec_regs[HOST_FRAME_SIZE];
>>>  static unsigned long exec_fp_regs[HOST_FP_SIZE];
>>>  static unsigned long exec_fpx_regs[HOST_XFP_SIZE];
>>> -static int have_fpx_regs = 1;
>>> +int have_fpx_regs = 1;
>>>  
>>>  void init_thread_registers(union uml_pt_regs *to)
>>>  {
>>> --- arch/um/sys-i386/signal.c.orig    2004-12-23 00:17:19.000000000 
>>> +0100
>>> +++ arch/um/sys-i386/signal.c    2004-12-23 11:41:41.928379633 +0100
>>> @@ -19,15 +19,37 @@
>>>  
>>>  #include "skas.h"
>>>  
>>> +
>>> +static inline unsigned short twd_i387_to_fxsr( unsigned short twd )
>>> +{
>>> +    unsigned int tmp; /* to avoid 16 bit prefixes in the code */
>>> +
>>> +    /* Transform each pair of bits into 01 (valid) or 00 (empty) */
>>> +    tmp = ~twd;
>>> +    tmp = (tmp | (tmp>>1)) & 0x5555; /* 0V0V0V0V0V0V0V0V */
>>> +    /* and move the valid bits to the lower byte. */
>>> +    tmp = (tmp | (tmp >> 1)) & 0x3333; /* 00VV00VV00VV00VV */
>>> +    tmp = (tmp | (tmp >> 2)) & 0x0f0f; /* 0000VVVV0000VVVV */
>>> +    tmp = (tmp | (tmp >> 4)) & 0x00ff; /* 00000000VVVVVVVV */
>>> +    return tmp;
>>> +}
>>> +
>>> +#define printk printf
>>> +
>>>  static int copy_sc_from_user_skas(struct pt_regs *regs,
>>>                    struct sigcontext *from)
>>>  {
>>>        struct sigcontext sc;
>>> -    unsigned long fpregs[HOST_FP_SIZE];
>>> -    int err;
>>> +    struct _fpstate * fp = (struct _fpstate *)regs->regs.skas.fp;
>>> +    int size, err, i;
>>> +
>>> +    if (have_fpx_regs)
>>> +        size = sizeof(struct _fpstate);
>>> +    else
>>> +        size = sizeof(regs->regs.skas.fp);
>>>  
>>>      err = copy_from_user(&sc, from, sizeof(sc));
>>> -    err |= copy_from_user(fpregs, sc.fpstate, sizeof(fpregs));
>>> +    err |= copy_from_user(fp, sc.fpstate, size);
>>>      if(err)
>>>          return(err);
>>>  
>>> @@ -48,23 +70,70 @@
>>>      REGS_EFLAGS(regs->regs.skas.regs) = sc.eflags;
>>>      REGS_SS(regs->regs.skas.regs) = sc.ss;
>>>  
>>> -    err = ptrace_setfpregs(userspace_pid[0], fpregs);
>>> -    if(err < 0){
>>> -          printk("copy_sc_from_user_skas - PTRACE_SETFPREGS failed, "
>>> -               "errno = %d\n", err);
>>> -        return(1);
>>> +    if (have_fpx_regs) {
>>> +        *(unsigned short *)fp->_fxsr_env = (unsigned short)(fp->cw & 
>>> 0xffff);
>>> +        *((unsigned short *)fp->_fxsr_env + 1) = (unsigned 
>>> short)(fp->sw & 0xffff);
>>> +        *((unsigned short *)fp->_fxsr_env + 2) = 
>>> twd_i387_to_fxsr(fp->tag & 0xffff);
>>> +        *((unsigned short *)fp->_fxsr_env + 3) = (unsigned 
>>> short)(fp->cssel >> 16);
>>> +        fp->_fxsr_env[2] = fp->ipoff;
>>> +        fp->_fxsr_env[3] = fp->cssel & 0xffff;
>>> +        fp->_fxsr_env[4] = fp->dataoff;
>>> +        fp->_fxsr_env[5] = fp->datasel;
>>> +        for ( i=0; i<8; i++)
>>> +        memcpy(fp->_fxsr_st+i, fp->_st+i, sizeof(struct _fpreg));
>>>      }
>>>  
>>>      return(0);
>>>  }
>>>  
>>> +static inline unsigned long twd_fxsr_to_i387( struct _fpstate *fp)
>>> +{
>>> +    struct _fpxreg *st = fp->_fxsr_st;
>>> +    unsigned long twd = fp->_fxsr_env[1] & 0x0000fffflu;
>>> +    unsigned long tag;
>>> +    unsigned long ret = 0xffff0000lu;
>>> +    int i;
>>> +
>>> +    for ( i = 0 ; i < 8 ; i++, st++ ) {
>>> +    if ( twd & 0x1 ) {
>>> +        switch ( st->exponent & 0x7fff ) {
>>> +        case 0x7fff:
>>> +            tag = 2;
>>> +            break;
>>> +        case 0x0000:
>>> +            if ( !st->significand[0] &&
>>> +                 !st->significand[1] &&
>>> +                 !st->significand[2] &&
>>> +                 !st->significand[3] ) {
>>> +            tag = 1;
>>> +            } else {
>>> +            tag = 2;
>>> +            }
>>> +            break;
>>> +        default:
>>> +            if ( st->significand[3] & 0x8000 ) {
>>> +            tag = 0;
>>> +            } else {
>>> +            tag = 2;
>>> +            }
>>> +            break;
>>> +        }
>>> +    } else {
>>> +        tag = 3;
>>> +    }
>>> +    ret |= (tag << (2 * i));
>>> +    twd = twd >> 1;
>>> +    }
>>> +    return ret;
>>> +}
>>> +
>>>  int copy_sc_to_user_skas(struct sigcontext *to, struct _fpstate *to_fp,
>>>               struct pt_regs *regs)
>>>  {
>>>        struct sigcontext sc;
>>> -    unsigned long fpregs[HOST_FP_SIZE];
>>> +    struct _fpstate * fp = (struct _fpstate *)regs->regs.skas.fp;
>>>      struct faultinfo * fi = &current->thread.arch.faultinfo;
>>> -    int err;
>>> +    int size, i;
>>>  
>>>      sc.gs = REGS_GS(regs->regs.skas.regs);
>>>      sc.fs = REGS_FS(regs->regs.skas.regs);
>>> @@ -87,20 +156,30 @@
>>>      sc.err = fi->error_code;
>>>      sc.trapno = fi->trap_no;
>>>  
>>> -    err = ptrace_getfpregs(userspace_pid[0], fpregs);
>>> -    if(err < 0){
>>> -          printk("copy_sc_to_user_skas - PTRACE_GETFPREGS failed, "
>>> -               "errno = %d\n", err);
>>> -        return(1);
>>> +    if (have_fpx_regs) {
>>> +        fp->cw = (unsigned long)*(unsigned short *)fp->_fxsr_env | 
>>> 0xffff0000ul;
>>> +        fp->sw = (unsigned long)*((unsigned short *)fp->_fxsr_env+1) 
>>> | 0xffff0000ul;
>>> +        fp->tag = twd_fxsr_to_i387(fp);
>>> +        fp->ipoff = fp->_fxsr_env[2];
>>> +        fp->cssel = fp->_fxsr_env[3] |
>>> +            ((unsigned long)*((unsigned short *)fp->_fxsr_env+3) << 
>>> 16);
>>> +        fp->dataoff = fp->_fxsr_env[4];
>>> +        fp->datasel = fp->_fxsr_env[5];
>>> +        fp->status = (unsigned short)(fp->sw & 0xfffful);
>>> +        fp->magic = 0;
>>> +        for ( i=0; i<8; i++)
>>> +        memcpy(fp->_st+i, fp->_fxsr_st+i, sizeof(struct _fpreg));
>>> +        size = sizeof(struct _fpstate);
>>> +    }
>>> +    else {
>>> +        *(unsigned long *)&fp->status = fp->sw;
>>> +        size = sizeof(regs->regs.skas.fp);
>>>      }
>>>      to_fp = (to_fp ? to_fp : (struct _fpstate *) (to + 1));
>>>      sc.fpstate = to_fp;
>>>  
>>> -    if(err)
>>> -          return(err);
>>> -
>>>      return(copy_to_user(to, &sc, sizeof(sc)) ||
>>> -           copy_to_user(to_fp, fpregs, sizeof(fpregs)));
>>> +           copy_to_user(to_fp, fp, size));
>>>  }
>>>  #endif
>>>  
>>> --- arch/um/kernel/skas/util/mk_ptregs-i386.c.orig    2004-12-23 
>>> 10:46:41.143243494 +0100
>>> +++ arch/um/kernel/skas/util/mk_ptregs-i386.c    2004-12-23 
>>> 11:08:01.272251951 +0100
>>> @@ -13,8 +13,9 @@
>>>      printf("#define __SKAS_PT_REGS_\n");
>>>      printf("\n");
>>>      printf("#define HOST_FRAME_SIZE %d\n", FRAME_SIZE);
>>> +    /* This needs to have space for "status", too */
>>>      printf("#define HOST_FP_SIZE %d\n", -           sizeof(struct 
>>> user_i387_struct) / sizeof(unsigned long));
>>> +           sizeof(struct user_i387_struct) / sizeof(unsigned long) + 
>>> 1);
>>>      printf("#define HOST_XFP_SIZE %d\n",             sizeof(struct 
>>> user_fxsr_struct) / sizeof(unsigned long));
>>>  
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel