From: Laurent Vivier <laurent@vivier.eu>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [RFC PATCH] linux-user/mmap: Return EFAULT for invalid addresses
Date: Tue, 16 Feb 2021 17:21:03 +0100 [thread overview]
Message-ID: <40acb232-a9da-951c-38fd-2fa1c529edd5@vivier.eu> (raw)
In-Reply-To: <0fb977ec30a318ace2bb1853b9cca7b8d7cfcea5.camel@linuxfoundation.org>
Le 16/02/2021 à 12:49, Richard Purdie a écrit :
> On Sat, 2021-02-13 at 18:40 +0100, Laurent Vivier wrote:
>> 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.purdie@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?
>
> Its taken me a short while to reproduce the test environment but I did
> so and can confirm that using EINVAL works just as well as EFAULT in
> the test case we have. The above would therefore seem to make sense to
> me and would fix the case we found.
Could you send a v2 of your patch with these changes?
Thanks,
Laurent
next prev parent reply other threads:[~2021-02-16 16:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 17:46 [RFC PATCH] linux-user/mmap: Return EFAULT for invalid addresses Richard Purdie
2021-01-22 9:37 ` Richard Purdie
2021-01-22 10:28 ` Philippe Mathieu-Daudé
2021-02-13 17:40 ` Laurent Vivier
2021-02-16 11:49 ` Richard Purdie
2021-02-16 16:21 ` Laurent Vivier [this message]
2021-02-16 19:01 ` [PATCH v2] linux-user/mmap: Return EFAULT/EINVAL " Richard Purdie
2021-02-16 19:13 ` Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40acb232-a9da-951c-38fd-2fa1c529edd5@vivier.eu \
--to=laurent@vivier.eu \
--cc=qemu-devel@nongnu.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).