On 10/6/22 08:38, Soichiro Isshiki wrote:
From: sisshiki1969
For now, qemu-x86_64 returns ENOMEM when mprotect() was called with an argument
len is 0 from a guest process.
This behavior is incompatible with the current Linux implementation,
which mprotect() with len = 0 does nothing and returns
Thank you for your response.
Yes, we can also modify guest_range_valid_untagged() like this:
static inline bool guest_range_valid_untagged(abi_ulong start, abi_ulong
len)
{
-return len - 1 <= GUEST_ADDR_MAX && start <= GUEST_ADDR_MAX - len + 1;
+ return !len || len - 1 <= GUEST_ADDR_MAX &
On 10/6/22 11:13, Peter Maydell wrote:
On Thu, 6 Oct 2022 at 19:05, Soichiro Isshiki
wrote:
From: sisshiki1969
For now, qemu-x86_64 returns ENOMEM when mprotect() was called with an argument
len is 0 from a guest process.
This behavior is incompatible with the current Linux implementation,
w
On Thu, 6 Oct 2022 at 19:05, Soichiro Isshiki
wrote:
>
> From: sisshiki1969
>
> For now, qemu-x86_64 returns ENOMEM when mprotect() was called with an
> argument
> len is 0 from a guest process.
> This behavior is incompatible with the current Linux implementation,
> which mprotect() with len =
From: sisshiki1969
For now, qemu-x86_64 returns ENOMEM when mprotect() was called with an argument
len is 0 from a guest process.
This behavior is incompatible with the current Linux implementation,
which mprotect() with len = 0 does nothing and returns 0,
although it does not appear to be explic
From: sisshiki1969
Signed-off-by: sisshiki1969
---
linux-user/mmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 28f3bc85ed..1ed79459ea 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -130,12 +130,12 @@ int targ