`,
performing the range check against the actual size of the target address
space. It also moves the corresponding block to prevent it from being
called incorrectly when the mapping itself fails.
Signed-off-by: Tobias Koch
---
linux-user/mmap.c | 21 -
1 file changed, 12
Ping
On 6/16/20 12:10 AM, Tobias Koch wrote:
> Ok, so according to the manpage, mremap generates EFAULT when "the range
> old_address to old_address+old_size is an
> invalid virtual memory address for this process". This is what the kernel
> does for the stack guard. Howe
to be
special-cased to fake kernel behavior.
I'm open to other suggestions. I also understand that the code duplication in
elfload.c and mmap.c to handle this is
undesirable, but the most viable alternative seems to be introducing more
globals.
On 6/15/20 11:28 PM, Tobias Koch wrote:
> Hm,
Hm, I see I need to have another look at this :)
On 6/15/20 10:17 AM, Tobias Koch wrote:
> Hi Laurent,
>
> the code in musl libc probing the stack is in
>
> https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c
>
> The setup in elfload.c doe
à 22:05, Tobias Koch a écrit :
>> If the address range starting at old_address overlaps with the stack guard it
>> is invalid and mremap must fail with EFAULT. The musl c library relies on
>> this
>> behavior to detect the stack size, which it does by doing consecutive mremaps
(such as the Ruby
interpreter) that calls pthread_getattr_np under musl will crash on 32 bit
targets emulated on a 64 bit host.
Signed-off-by: Tobias Koch
---
linux-user/mmap.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index
Analogous to what commit 5dfa88f7 did for setrlimit, this commit
selectively ignores limits for memory-related resources in prlimit64
calls. This is to prevent too restrictive limits from causing QEMU
itself to malfunction.
Signed-off-by: Tobias Koch
---
linux-user/syscall.c | 5 -
1 file
Analogous to what commit 5dfa88f7 did for setrlimit, this commit
selectively ignores limits for memory-related resources in prlimit64
calls. This is to prevent too restrictive limits from causing QEMU
itself to malfunction.
Signed-off-by: Tobias Koch
---
linux-user/syscall.c | 16
I carried out the following test:
* fetched the QEMU coming with 18.04,
* added this patch,
* built an LXD container with arch arm64 and the patched qemu-aarch64-static
inside,
* launched it on amd64
Previously various systemd services would not come up properly, now they
are running like a char
Thanks, Laurent! I'll get back to you, asap.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Status in QEMU:
Confirmed
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Status in QEMU:
Con
I'm a bit surprised that this bug doesn't get more attention, as it
makes it very hard to run qemu-emulated containers of Bionic hosted on
Bionic. Running such containers is a common way to cross-compile
packages for foreign architectures in the absence of sufficiently
powerful target HW.
The docu
12 matches
Mail list logo
