headers
Américo Wang | 1 Apr 2009 17:49
Picon

Re: [patch 1/3] uml: fix compile error from net_device_ops conversion

On Mon, Mar 30, 2009 at 08:41:10PM +0200, Miklos Szeredi wrote:
>From: Miklos Szeredi <mszeredi <at> suse.cz>
>
>Fix the following compile error:
>
>arch/um/drivers/net_kern.c: In function 'uml_inetaddr_event':
>arch/um/drivers/net_kern.c:760: error: 'struct net_device' has no member named 'open'
>
>This was introduced by commit 8bb95b39, "uml: convert network device
>to netdevice ops".
>
>Signed-off-by: Miklos Szeredi <mszeredi <at> suse.cz>

Reviewed-by: WANG Cong <xiyou.wangcong <at> gmail.com>

Thanks.

>---
> arch/um/drivers/net_kern.c |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>Index: linux-2.6/arch/um/drivers/net_kern.c
>===================================================================
>--- linux-2.6.orig/arch/um/drivers/net_kern.c	2009-03-30 17:07:10.000000000 +0200
>+++ linux-2.6/arch/um/drivers/net_kern.c	2009-03-30 19:25:30.000000000 +0200
> <at>  <at>  -757,7 +757,7  <at>  <at>  static int uml_inetaddr_event(struct not
> 	void (*proc)(unsigned char *, unsigned char *, void *);
> 	unsigned char addr_buf[4], netmask_buf[4];
> 
>-	if (dev->open != uml_net_open)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Américo Wang | 1 Apr 2009 18:03
Picon

Re: [patch 2/3] uml: fix link error from prefixing of i386 syscalls with ptregs_

On Mon, Mar 30, 2009 at 08:47:12PM +0200, Miklos Szeredi wrote:
>From: Miklos Szeredi <mszeredi <at> suse.cz>
>
>Fix the following link error:
>
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x11c): undefined reference to `ptregs_fork'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x140): undefined reference to `ptregs_execve'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x2cc): undefined reference to `ptregs_iopl'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x2d8): undefined reference to `ptregs_vm86old'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x2f0): undefined reference to `ptregs_sigreturn'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x2f4): undefined reference to `ptregs_clone'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x3ac): undefined reference to `ptregs_vm86'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x3c8): undefined reference to `ptregs_rt_sigreturn'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x3fc): undefined reference to `ptregs_sigaltstack'
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x40c): undefined reference to `ptregs_vfork'
>
>This was introduced by commit 253f29a4, "x86: pass in pt_regs pointer
>for syscalls that need it"
>
>Signed-off-by: Miklos Szeredi <mszeredi <at> suse.cz>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Américo Wang | 1 Apr 2009 18:11
Picon

do_execve() needs const qualifiers (was Re: [patch 3/3] uml: fix warnings in kernel_execve)

On Mon, Mar 30, 2009 at 08:45:12PM +0200, Miklos Szeredi wrote:
>From: Miklos Szeredi <mszeredi <at> suse.cz>
>
>Fix the following warnings:
>
>arch/um/kernel/syscall.c: In function 'kernel_execve':
>arch/um/kernel/syscall.c:130: warning: passing argument 1 of 'um_execve' discards qualifiers from
pointer target type
>arch/um/kernel/syscall.c:130: warning: passing argument 2 of 'um_execve' discards qualifiers from
pointer target type
>arch/um/kernel/syscall.c:130: warning: passing argument 3 of 'um_execve' discards qualifiers from
pointer target type
>
>Signed-off-by: Miklos Szeredi <mszeredi <at> suse.cz>
>---
> arch/um/kernel/syscall.c |    3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>Index: linux-2.6/arch/um/kernel/syscall.c
>===================================================================
>--- linux-2.6.orig/arch/um/kernel/syscall.c	2009-03-30 20:25:17.000000000 +0200
>+++ linux-2.6/arch/um/kernel/syscall.c	2009-03-30 20:36:20.000000000 +0200
> <at>  <at>  -127,7 +127,8  <at>  <at>  int kernel_execve(const char *filename,
> 
> 	fs = get_fs();
> 	set_fs(KERNEL_DS);
>-	ret = um_execve(filename, argv, envp);
>+	ret = um_execve((char *)filename, (char __user *__user *)argv,
>+			(char __user *__user *) envp);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Viro | 1 Apr 2009 18:21
Picon

Re: do_execve() needs const qualifiers (was Re: [patch 3/3] uml: fix warnings in kernel_execve)

On Thu, Apr 02, 2009 at 12:11:14AM +0800, Am??rico Wang wrote:
> On Mon, Mar 30, 2009 at 08:45:12PM +0200, Miklos Szeredi wrote:
> >From: Miklos Szeredi <mszeredi <at> suse.cz>
> >
> >Fix the following warnings:
> >
> >arch/um/kernel/syscall.c: In function 'kernel_execve':
> >arch/um/kernel/syscall.c:130: warning: passing argument 1 of 'um_execve' discards qualifiers from
pointer target type
> >arch/um/kernel/syscall.c:130: warning: passing argument 2 of 'um_execve' discards qualifiers from
pointer target type
> >arch/um/kernel/syscall.c:130: warning: passing argument 3 of 'um_execve' discards qualifiers from
pointer target type
> >
> >Signed-off-by: Miklos Szeredi <mszeredi <at> suse.cz>
> >---
> > arch/um/kernel/syscall.c |    3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >Index: linux-2.6/arch/um/kernel/syscall.c
> >===================================================================
> >--- linux-2.6.orig/arch/um/kernel/syscall.c	2009-03-30 20:25:17.000000000 +0200
> >+++ linux-2.6/arch/um/kernel/syscall.c	2009-03-30 20:36:20.000000000 +0200
> > <at>  <at>  -127,7 +127,8  <at>  <at>  int kernel_execve(const char *filename,
> > 
> > 	fs = get_fs();
> > 	set_fs(KERNEL_DS);
> >-	ret = um_execve(filename, argv, envp);
> >+	ret = um_execve((char *)filename, (char __user *__user *)argv,
> >+			(char __user *__user *) envp);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Renzo Davoli | 4 Apr 2009 12:17
Picon

Re: [PATCH 0/2] ptrace_vm: ptrace for syscall emulation virtual machines

Dear Cong,

On Mon, Mar 30, 2009 at 12:32:28AM +0800, Américo Wang wrote:
> On Wed, Mar 25, 2009 at 12:47:53AM +0100, Renzo Davoli wrote:
> >1- the code is now extremely simple 
> Why adding a new request for ptrace is harder? I don't think so. :)
> >2- if we define a different tag for syscall (e.g. PTRACE_VM), we need also
> >different tags for PTRACE_VM_SINGLESTEP, PTRACE_VM_SINGLEBLOCK and maybe
> >others in the future.
> >Using the addr field we don't need this multiplication of tags
> >(and we could soon delete PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP).
> Yes? We could also remove PTRACE_SYSEMU* if we had PTRACE_VM to replace
> it. I would like to hear more from you on this point.

I am sorry for the delay of this reply.
I am having a quite busy time and I like to analyze problems before
giving answers.

Let me point out that the primary issue is the following one:
PTRACE_SYSEMU is a limited feature. It is twofold limited:
- it is supported only for x86
- it provides support for "total" virtual machines like User-Mode Linux
and it is useless for "partial" virtual machine like fakeroot-ng, umview
or others.
I have published a proposal for a new support that is able to overpass
these limits. PTRACE_SYSEMU/SYSEMU_SINGLESTEP could be deprecated.
There will be some cleaning up of the kernel code when the deprecated
tags are eliminated.

Whether it is nicer to use the existing tags or defining new tags is a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Américo Wang | 4 Apr 2009 18:51
Picon

Re: do_execve() needs const qualifiers (was Re: [patch 3/3] uml: fix warnings in kernel_execve)

On Wed, Apr 01, 2009 at 05:21:22PM +0100, Al Viro wrote:
>On Thu, Apr 02, 2009 at 12:11:14AM +0800, Am??rico Wang wrote:
>> On Mon, Mar 30, 2009 at 08:45:12PM +0200, Miklos Szeredi wrote:
>> >From: Miklos Szeredi <mszeredi <at> suse.cz>
>> >
>> >Fix the following warnings:
>> >
>> >arch/um/kernel/syscall.c: In function 'kernel_execve':
>> >arch/um/kernel/syscall.c:130: warning: passing argument 1 of 'um_execve' discards qualifiers
from pointer target type
>> >arch/um/kernel/syscall.c:130: warning: passing argument 2 of 'um_execve' discards qualifiers
from pointer target type
>> >arch/um/kernel/syscall.c:130: warning: passing argument 3 of 'um_execve' discards qualifiers
from pointer target type
>> >
>> >Signed-off-by: Miklos Szeredi <mszeredi <at> suse.cz>
>> >---
>> > arch/um/kernel/syscall.c |    3 ++-
>> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> >Index: linux-2.6/arch/um/kernel/syscall.c
>> >===================================================================
>> >--- linux-2.6.orig/arch/um/kernel/syscall.c	2009-03-30 20:25:17.000000000 +0200
>> >+++ linux-2.6/arch/um/kernel/syscall.c	2009-03-30 20:36:20.000000000 +0200
>> > <at>  <at>  -127,7 +127,8  <at>  <at>  int kernel_execve(const char *filename,
>> > 
>> > 	fs = get_fs();
>> > 	set_fs(KERNEL_DS);
>> >-	ret = um_execve(filename, argv, envp);
>> >+	ret = um_execve((char *)filename, (char __user *__user *)argv,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Américo Wang | 7 Apr 2009 19:36
Picon

Re: [PATCH 0/2] ptrace_vm: ptrace for syscall emulation virtual machines

On Sat, Apr 04, 2009 at 12:17:09PM +0200, Renzo Davoli wrote:
>Dear Cong,
>
>On Mon, Mar 30, 2009 at 12:32:28AM +0800, Américo Wang wrote:
>> On Wed, Mar 25, 2009 at 12:47:53AM +0100, Renzo Davoli wrote:
>> >1- the code is now extremely simple 
>> Why adding a new request for ptrace is harder? I don't think so. :)
>> >2- if we define a different tag for syscall (e.g. PTRACE_VM), we need also
>> >different tags for PTRACE_VM_SINGLESTEP, PTRACE_VM_SINGLEBLOCK and maybe
>> >others in the future.
>> >Using the addr field we don't need this multiplication of tags
>> >(and we could soon delete PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP).
>> Yes? We could also remove PTRACE_SYSEMU* if we had PTRACE_VM to replace
>> it. I would like to hear more from you on this point.
>
>I am sorry for the delay of this reply.
>I am having a quite busy time and I like to analyze problems before
>giving answers.

No problem. :)

>
>Let me point out that the primary issue is the following one:
>PTRACE_SYSEMU is a limited feature. It is twofold limited:
>- it is supported only for x86
>- it provides support for "total" virtual machines like User-Mode Linux
>and it is useless for "partial" virtual machine like fakeroot-ng, umview
>or others.
>I have published a proposal for a new support that is able to overpass
>these limits. PTRACE_SYSEMU/SYSEMU_SINGLESTEP could be deprecated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo van Lil | 7 Apr 2009 19:47
Picon
Picon

Multi-threaded applications and floating point registers

Hello there,

I'm experiencing some weird problems with a multi-threaded application 
I'm working on: A function which uses nothing but a single input value, 
a few constants and a couple of floating point operations returns wrong 
results from time to time. The application uses multiple threads, and 
we're suspecting that the FPU state isn't properly saved and restored 
when switching between threads within a process.

I've written a trivial test program which can be used to reproduce the 
issue (see below). In theory the program should run forever, but in UML 
it aborts after just a few seconds.

I have observed the issue both with kernel 2.6.28.8 and Busybox/uclibc 
and with the demo kernel 2.6.24-rc7 and the Fedora10 image from the UML 
home page. The problem does not happen with kernel 2.6.23.1. We're 
suspecting that the problem has been introduced by the patch [1] to stop 
saving the process FP state which has been applied just before 2.6.24-rc1.

Regards,
Ingo

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=42daba316557e597a90a730f61c762602b7f0e0c

======================================================================

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stanislav Meduna | 7 Apr 2009 20:27
Favicon

Re: Multi-threaded applications and floating point registers

Ingo van Lil wrote:

> I'm experiencing some weird problems with a multi-threaded application 
> I'm working on: A function which uses nothing but a single input value, 
> a few constants and a couple of floating point operations returns wrong 
> results from time to time. The application uses multiple threads, and 
> we're suspecting that the FPU state isn't properly saved and restored 
> when switching between threads within a process.

I had a similar problem between processes a few months ago,
I also posted an example, unfortunately with no resolution
nor further inquiries from the developers. I suspect the skas3
patch does not get much attention now...

Try to run the guest with mode=skas0 - in my case it eliminated
the problem and the guest is running for months without a hiccup.
If your problem is the same, it will probably help as well.

> We're suspecting that the problem has been introduced by the
> patch [1] to stop saving the process FP state which has been
> applied just before 2.6.24-rc1.

In my case it was reproducible with 2.6.23.17 as well.

Regards
--

-- 
                                      Stano

------------------------------------------------------------------------------
This SF.net email is sponsored by:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ingo van Lil | 7 Apr 2009 23:23
Picon
Picon

Re: Multi-threaded applications and floating point registers

Stanislav Meduna wrote:

>> I'm experiencing some weird problems with a multi-threaded application 
>> I'm working on: A function which uses nothing but a single input value, 
>> a few constants and a couple of floating point operations returns wrong 
>> results from time to time. The application uses multiple threads, and 
>> we're suspecting that the FPU state isn't properly saved and restored 
>> when switching between threads within a process.
> 
> I had a similar problem between processes a few months ago,
> I also posted an example, unfortunately with no resolution
> nor further inquiries from the developers. I suspect the skas3
> patch does not get much attention now...

Yes, I remember the thread. I don't think we're hitting the same
problem, though: I'm not using the SKAS3 patch, and I did not notice any
kind of cross-process influence. The effect is limited to threads
sharing a single process context.

Regards,
Ingo

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
Permalink | Reply | 0 comments |

Gmane