On Wed, 2007-11-07 at 20:18 +0100, Fabrice Bellard wrote:
> - Fix page_check_range() so that it handles writes to pages containing
> code by calling page_unprotect when necessary (the current code can fail
> in this case !).
>
> - Suppress no longer needed page_unprotect_range() call in syscall.
> - Modify lock_user() so that it automatically does access_ok() and
> returns NULL if access_ok() fails.
You'll also need to augment all lock_user calls to indicate whether the buffer
needs to be writable. Currently this information is not available until
unlock_user is called.
Paul
On Wed, 2007-11-07 at 20:18 +0100, Fabrice Bellard wrote:
> Hi,
>
> Regarding the user memory access, here is my suggestion which should
> minimize the changes:
The virtue of making the minimum changes is that there are likely fewer
errors. Other than that, it's more important to me to make the
Hi,
Regarding the user memory access, here is my suggestion which should
minimize the changes:
- Keep __put_user() and __get_user() as you did.
- Remove put_user(), get_user(), copy_from_user() and copy_to_user()
- Modify the signal.c code so that it uses __put_user, __get_user and
lock/unlock_
On Tue, 6 Nov 2007, Paul Brook wrote:
If you're not careful you get double-copying. Once copying the struct from
guest to host space, and then again when converting layout/endianess.
Yes, it would be easy to do that by mistake. The approach that has been
taken has been to use typed copy_*_user
> By the time you consider the different combinations of targets & hosts,
> most of the opportunities for zero copy are eliminated anyway. Byte
> ordering and structure packing amd content differences mean that we can't
> do zero-copy except in the rare circumstance that the host & target
> match i
On Tue, 6 Nov 2007, Fabrice Bellard wrote:
Paul Brook wrote:
[...]
Personally I like the locking interface as it allows a zero-copy
implementation. However the kernel uses a copying interface, and my
understanding is that other qemu maintainers also prefer the copying
interface.
At least I do
Paul Brook wrote:
> [...]
> Personally I like the locking interface as it allows a zero-copy
> implementation. However the kernel uses a copying interface, and my
> understanding is that other qemu maintainers also prefer the copying
> interface.
At least I don't think it is critical performanc
Here's a better explanation as to why I initially mixed lock_user() and
copy_to_user():
On Tue, 2007-11-06 at 01:05 +, Paul Brook wrote:
> > access_ok() and lock_user() perform essential functions. lock_user(),
> > however, isn't directly comparable to how the kernel operates and should
> > t
> access_ok() and lock_user() perform essential functions. lock_user(),
> however, isn't directly comparable to how the kernel operates and should
> therefore be encapsulated inside more typical kernel functions such as
> {get,put}_user(), copy_{to,from}_user() and the like. access_ok() and
> loc
On Sat, 2007-11-03 at 18:52 +0100, Paul Brook wrote:
> On Saturday 03 November 2007, TJ wrote:
> > I'm building on x86_64 GNU/Linux. There are *lots* of (1053) compiler
> > warnings of the class:
> >
> > warning: cast to pointer from integer of different size
>
> There are at due to the recent EF
On Saturday 03 November 2007, TJ wrote:
> I'm building on x86_64 GNU/Linux. There are *lots* of (1053) compiler
> warnings of the class:
>
> warning: cast to pointer from integer of different size
There are at due to the recent EFAULT/access_ok changes. There should be (and
used to be) a clear se
I'm building on x86_64 GNU/Linux. There are *lots* of (1053) compiler
warnings of the class:
warning: cast to pointer from integer of different size
caused by the various conversions to/from host-to-target pointer and int
types.
On x86 the warnings mostly don't occur. An easy way to get an idea
13 matches
Mail list logo
