Hi,

thank you! And yes, you are absolutely right. QEMU always fails in mmap.c after looking at page flags in the extended memory range:

        int prot = 0;
        if (reserved_va && old_size < new_size) {
            abi_ulong addr;
            for (addr = old_addr + old_size;
                 addr < old_addr + new_size;
                 addr++) {
                prot |= page_get_flags(addr);
            }
        }
        if (prot == 0) {
            host_addr = mremap(g2h(old_addr), old_size, new_size, flags);
            if (host_addr != MAP_FAILED && reserved_va && old_size > new_size) {
                mmap_reserve(old_addr + old_size, new_size - old_size);
            }
        } else {
	    /* musl's pthread_getattr_np always fails here doing mremaps: */
 	    errno = ENOMEM;
            host_addr = MAP_FAILED;
        }

I wonder why it cannot just try the remap directly and use the result of that, but that's clearly a question for the QEMU people.

Tobias


On 21/06/2017 03:41, Rich Felker wrote:
[...]
OK, qemu-user is just emulating mremap very poorly. The man page
documents that it fails with EFAULT when the address passed is not
valid, but qemu seems to be giving ENOMEM, which has a different
meaning. I remember we looked hard when this was first implemented to
find an acceptable/safe way to probe for valid pages, so I doubt we'll
find a better or equally good way that both works around the bug in
qemu-user and does the right thing on all real kernels. I think the
qemu bug should just be reported and fixed.

Rich