* [PATCH] linux-user/elfload: use MAP_FIXED in pgb_reserved_va
@ 2020-06-30 10:34 Alex Bennée
2020-06-30 13:10 ` Peter Maydell
0 siblings, 1 reply; 4+ messages in thread
From: Alex Bennée @ 2020-06-30 10:34 UTC (permalink / raw)
To: qemu-devel
Cc: Alex Bennée, Riku Voipio, richard.henderson, Laurent Vivier
Given we assert the requested address matches what we asked we should
also make that clear in the mmap flags. Otherwise we see failures in
the GitLab environment for some currently unknown but allowable
reason.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
linux-user/elfload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index b5cb21384a1..be8facfbcc8 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2294,7 +2294,7 @@ static void pgb_dynamic(const char *image_name, long align)
static void pgb_reserved_va(const char *image_name, abi_ulong guest_loaddr,
abi_ulong guest_hiaddr, long align)
{
- const int flags = MAP_ANONYMOUS | MAP_PRIVATE | MAP_NORESERVE;
+ const int flags = MAP_ANONYMOUS | MAP_PRIVATE | MAP_NORESERVE | MAP_FIXED;
void *addr, *test;
if (guest_hiaddr > reserved_va) {
--
2.20.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] linux-user/elfload: use MAP_FIXED in pgb_reserved_va
2020-06-30 10:34 [PATCH] linux-user/elfload: use MAP_FIXED in pgb_reserved_va Alex Bennée
@ 2020-06-30 13:10 ` Peter Maydell
2020-06-30 14:41 ` Alex Bennée
0 siblings, 1 reply; 4+ messages in thread
From: Peter Maydell @ 2020-06-30 13:10 UTC (permalink / raw)
To: Alex Bennée
Cc: Riku Voipio, Richard Henderson, QEMU Developers, Laurent Vivier
On Tue, 30 Jun 2020 at 11:36, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Given we assert the requested address matches what we asked we should
> also make that clear in the mmap flags. Otherwise we see failures in
> the GitLab environment for some currently unknown but allowable
> reason.
Adding MAP_FIXED will mean that instead of failing if there's
something else already at that address, the kernel will now
silently blow that away in favour of the new mapping. Is
that definitely what we want here ?
thanks
-- PMM
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] linux-user/elfload: use MAP_FIXED in pgb_reserved_va
2020-06-30 13:10 ` Peter Maydell
@ 2020-06-30 14:41 ` Alex Bennée
2020-07-02 19:52 ` Richard Henderson
0 siblings, 1 reply; 4+ messages in thread
From: Alex Bennée @ 2020-06-30 14:41 UTC (permalink / raw)
To: Peter Maydell
Cc: Riku Voipio, Richard Henderson, QEMU Developers, Laurent Vivier
Peter Maydell <peter.maydell@linaro.org> writes:
> On Tue, 30 Jun 2020 at 11:36, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Given we assert the requested address matches what we asked we should
>> also make that clear in the mmap flags. Otherwise we see failures in
>> the GitLab environment for some currently unknown but allowable
>> reason.
>
> Adding MAP_FIXED will mean that instead of failing if there's
> something else already at that address, the kernel will now
> silently blow that away in favour of the new mapping. Is
> that definitely what we want here ?
Hmm maybe not. But hey I just noticed that we have MAP_FIXED_NOREPLACE
(since Linux 4.17) which says:
This flag provides behavior that is similar to MAP_FIXED with
respect to the addr enforcement, but differs in that
MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.
If the requested range would collide with an existing mapping,
then this call fails with the error EEXIST. This flag can
therefore be used as a way to atomically (with respect to other
threads) attempt to map an address range: one thread will suc‐
ceed; all others will report failure.
Note that older kernels which do not recognize the
MAP_FIXED_NOREPLACE flag will typically (upon detecting a colli‐
sion with a preexisting mapping) fall back to a "non-MAP_FIXED"
type of behavior: they will return an address that is different
from the requested address. Therefore, backward-compatible
software should check the returned address against the requested
address.
So maybe that is what we should do?
Now you've pointed that out I wonder if we need to fix
pgd_find_hole_fallback as well?
>
> thanks
> -- PMM
--
Alex Bennée
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] linux-user/elfload: use MAP_FIXED in pgb_reserved_va
2020-06-30 14:41 ` Alex Bennée
@ 2020-07-02 19:52 ` Richard Henderson
0 siblings, 0 replies; 4+ messages in thread
From: Richard Henderson @ 2020-07-02 19:52 UTC (permalink / raw)
To: Alex Bennée, Peter Maydell
Cc: Riku Voipio, QEMU Developers, Laurent Vivier
On 6/30/20 7:41 AM, Alex Bennée wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On Tue, 30 Jun 2020 at 11:36, Alex Bennée <alex.bennee@linaro.org> wrote:
>>>
>>> Given we assert the requested address matches what we asked we should
>>> also make that clear in the mmap flags. Otherwise we see failures in
>>> the GitLab environment for some currently unknown but allowable
>>> reason.
>>
>> Adding MAP_FIXED will mean that instead of failing if there's
>> something else already at that address, the kernel will now
>> silently blow that away in favour of the new mapping. Is
>> that definitely what we want here ?
>
> Hmm maybe not.
Definitely not.
> But hey I just noticed that we have MAP_FIXED_NOREPLACE
> (since Linux 4.17) which says:
>
> This flag provides behavior that is similar to MAP_FIXED with
> respect to the addr enforcement, but differs in that
> MAP_FIXED_NOREPLACE never clobbers a preexisting mapped range.
> If the requested range would collide with an existing mapping,
> then this call fails with the error EEXIST. This flag can
> therefore be used as a way to atomically (with respect to other
> threads) attempt to map an address range: one thread will suc‐
> ceed; all others will report failure.
>
> Note that older kernels which do not recognize the
> MAP_FIXED_NOREPLACE flag will typically (upon detecting a colli‐
> sion with a preexisting mapping) fall back to a "non-MAP_FIXED"
> type of behavior: they will return an address that is different
> from the requested address. Therefore, backward-compatible
> software should check the returned address against the requested
> address.
>
> So maybe that is what we should do?
Yes, that would be better, because those are the exact semantics that we want.
Though it would be Really Nice to know what's up with gitlab...
> Now you've pointed that out I wonder if we need to fix
> pgd_find_hole_fallback as well?
Yes, that could benefit from MAP_FIXED_NOREPLACE.
I do think there's a way we could streamline the 32-on-64 case. At present we
are groveling through /proc/self/maps, or mmaping+unmaping, and then mmaping.
Whereas we could just mmap once and be done -- it's the 32-on-32 case that
requires the song and dance.
r~
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-07-02 19:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-30 10:34 [PATCH] linux-user/elfload: use MAP_FIXED in pgb_reserved_va Alex Bennée
2020-06-30 13:10 ` Peter Maydell
2020-06-30 14:41 ` Alex Bennée
2020-07-02 19:52 ` Richard Henderson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.