Le 08/01/2021 à 18:46, Richard Purdie a écrit : > When using qemu-i386 to run gobject introspection parts of a webkitgtk > build using musl as libc on a 64 bit host, it sits in an infinite loop > of mremap calls of ever decreasing/increasing addresses. > > I suspect something in the musl memory allocation code loops indefinitely > if it only sees ENOMEM and only exits when it hits EFAULT. > > According to the docs, trying to mremap outside the address space > can/should return EFAULT and changing this allows the build to succeed. > > There was previous discussion of this as it used to work before qemu 2.11 > and we've carried hacks to work around it since, this appears to be a > better fix of the real issue? > > Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org > > Index: qemu-5.2.0/linux-user/mmap.c > =================================================================== > --- qemu-5.2.0.orig/linux-user/mmap.c > +++ qemu-5.2.0/linux-user/mmap.c > @@ -727,7 +727,7 @@ abi_long target_mremap(abi_ulong old_add > !guest_range_valid(new_addr, new_size)) || > ((flags & MREMAP_MAYMOVE) == 0 && > !guest_range_valid(old_addr, new_size))) { > - errno = ENOMEM; > + errno = EFAULT; > return -1; > } > > >
I agree with that, the ENOMEM is returned when there is not enough virtual memory (the mmap_find_vma() case). According to the manpage, EFAULT is returned when old_addr and old_addr + old_size is an invalid address space. So: if (!guest_range_valid(old_addr, old_size)) { errno = EFAULT; return -1; } But in the case of new_size and new_addr, it seems the good value to use is EINVAL. So: if (((flags & MREMAP_FIXED) && !guest_range_valid(new_addr, new_size)) || ((flags & MREMAP_MAYMOVE) == 0 && !guest_range_valid(old_addr, new_size))) { errno = EINVAL; return -1; } Did you try that? Thanks, Laurent