qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: [0/11] EFAULT patch


From: Stuart Anderson
Subject: Re: [Qemu-devel] RFC: [0/11] EFAULT patch
Date: Wed, 19 Sep 2007 15:00:18 -0400 (EDT)

On Wed, 19 Sep 2007, J. Mayer wrote:

Then, the changes you've done, changing long arguments (which should be
target_long to be correct, you can take a look at the last patch I sent
on the list) to pointers, for example in function prototypes, are
incorrect.

I just went, and looked at the linux code again for 32 on 64 for x86_64 and
powerpc.  In both of these cases (and I suspect the others as well), the
parameters which are passed via registers are 0 extended from 32 bits to
64 bit in the syscall entry asm code. This way, once the C code is
called via the sys_call_table, everything is dealt with as 64 bits. This
actually keeps the rest of the code simpler as the rest of the kernel
doesn't have to be extending & truncating pointers everywhere else.

On x86_64 and powerpc, it appears that both user (ie target) and kernel
pointers co-exist and that the code that maps structures assume that the
__get_user()/__put_user() and copy_*_user() routines can handle any
special situation. The pointers passed into functions like
cp_compat_stat() are 64-bits for both the structure located in the
kernel, and the one located in user space.

My understanding is that we want to do as the kernel does as much as
possible. In light of this, wouldn't we want to be decreasing the use
of target_long where pointers may be involved instead of increasing it?


                                Stuart

Stuart R. Anderson                               address@hidden
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                 BD03 0A62 E534 37A7 9149




reply via email to

[Prev in Thread] Current Thread [Next in Thread]