qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] oslib-posix: Use MAP_STACK in qemu_alloc_stack(


From: Kamil Rytarowski
Subject: Re: [Qemu-devel] [PATCH] oslib-posix: Use MAP_STACK in qemu_alloc_stack() on OpenBSD
Date: Thu, 11 Oct 2018 21:31:23 +0200
User-agent: Mozilla/5.0 (X11; NetBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 11.10.2018 16:25, Brad Smith wrote:
> On 10/11/2018 5:41 AM, Kamil Rytarowski wrote:
> 
>> On 11.10.2018 11:36, Peter Maydell wrote:
>>> On 11 October 2018 at 00:55, Brad Smith <address@hidden> wrote:
>>>> And from FreeBSD...
>>>>
>>>>       MAP_STACK MAP_STACK implies MAP_ANON, and offset of 0.  The fd
>>>> argument must be -1 and prot must include at least
>>>> PROT_READ and PROT_WRITE.
>>>>
>>>> This option creates a memory region that grows to at
>>>> most len bytes in size, starting from the stack top
>>>> and growing down.  The stack top is the starting
>>>> address returned by the call, plus len bytes.  The
>>>> bottom of the stack at maximum growth is the starting
>>>> address returned by the call.
>>>>
>>>> Stacks created with MAP_STACK automatically grow.
>>>> Guards prevent inadvertent use of the regions into
>>>> which those stacks can grow without requiring mapping
>>>> the whole stack in advance.
>>> Hmm. That "automatically growing" part sounds like
>>> behaviour we definitely do not want for our use case.
>>> So we're going to need to make this OS-specific :-(
>>>
>> I propose to restrict MAP_STACK it to OpenBSD (with a comment in the
>> code). Once it will be needed by someone else will be able to enable it
>> for other OSes.
> 
> I was going to propose doing something like that but you had replied
> before I did.
> What sort of comment did you have in mind?
> 

Why do we want it only on OpenBSD and its either unneeded or meaning
something else on other OSes.

#ifdef __OpenBSD__
flags |= MAP_STACK;
#endif

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]