From: Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org>
To: James Bottomley
<James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>,
James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-parisc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
John David Anglin <dave.anglin-CzeTG9NwML0@public.gmane.org>,
linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] parisc,metag: Do not hardcode maximum userspace stack size
Date: Sun, 04 May 2014 09:28:05 +0200 [thread overview]
Message-ID: <5365EC05.5080900@gmx.de> (raw)
In-Reply-To: <1399042116.2202.1.camel@dabdike>
On 05/02/2014 04:48 PM, James Bottomley wrote:
> On Fri, 2014-05-02 at 12:54 +0100, James Hogan wrote:
>> On 01/05/14 18:50, James Bottomley wrote:
>>>
>>>> +
>>>> +config MAX_STACK_SIZE_MB
>>>> + int "Maximum user stack size (MB)"
>>>> + default 80
>>>> + range 8 256 if METAG
>>>> + range 8 2048
>>>> + depends on STACK_GROWSUP
>>>> + help
>>>> + This is the maximum stack size in Megabytes in the VM layout of user
>>>> + processes when the stack grows upwards (currently only on parisc and
>>>> + metag arch). The stack will be located at the highest memory address
>>>> + minus the given value, unless the RLIMIT_STACK hard limit is changed
>>>> + to a smaller value in which case that is used.
>>>> +
>>>> + A sane initial value is 80 MB.
>>>
>>> There's one final issue with this: placement of the stack only really
>>> matters on 32 bits. We have three expanding memory areas: stack, heap
>>> and maps. On 64 bits these are placed well separated from each other on
>>> 64 bits, so an artificial limit like this doesn't matter.
>>
>> Does the following fixup diff look reasonable? It forces
>> MAX_STACK_SIZE_MB to 1024 and hides the Kconfig option for 64BIT,
>> effectively leaving the behaviour unchanged in that case.
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index e80075979530..b0307f737bd7 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -583,7 +583,8 @@ config GENERIC_EARLY_IOREMAP
>> bool
>>
>> config MAX_STACK_SIZE_MB
>> - int "Maximum user stack size (MB)"
>> + int "Maximum user stack size (MB)" if !64BIT
>> + default 1024 if 64BIT
>> default 80
>> range 8 256 if METAG
>> range 8 2048
>
> Yes, I think that's probably correct ...
No, it's not correct.
It will then choose then a 1GB stack for compat tasks on 64bit kernel.
Helge
> parisc doesn't actually have
> anything other than a testbed 64 bit userspace, so this is a bit
> theoretical for us.
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Helge Deller <deller@gmx.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
James Hogan <james.hogan@imgtec.com>
Cc: linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
John David Anglin <dave.anglin@bell.net>,
linux-metag@vger.kernel.org
Subject: Re: [PATCH] parisc,metag: Do not hardcode maximum userspace stack size
Date: Sun, 04 May 2014 09:28:05 +0200 [thread overview]
Message-ID: <5365EC05.5080900@gmx.de> (raw)
In-Reply-To: <1399042116.2202.1.camel@dabdike>
On 05/02/2014 04:48 PM, James Bottomley wrote:
> On Fri, 2014-05-02 at 12:54 +0100, James Hogan wrote:
>> On 01/05/14 18:50, James Bottomley wrote:
>>>
>>>> +
>>>> +config MAX_STACK_SIZE_MB
>>>> + int "Maximum user stack size (MB)"
>>>> + default 80
>>>> + range 8 256 if METAG
>>>> + range 8 2048
>>>> + depends on STACK_GROWSUP
>>>> + help
>>>> + This is the maximum stack size in Megabytes in the VM layout of user
>>>> + processes when the stack grows upwards (currently only on parisc and
>>>> + metag arch). The stack will be located at the highest memory address
>>>> + minus the given value, unless the RLIMIT_STACK hard limit is changed
>>>> + to a smaller value in which case that is used.
>>>> +
>>>> + A sane initial value is 80 MB.
>>>
>>> There's one final issue with this: placement of the stack only really
>>> matters on 32 bits. We have three expanding memory areas: stack, heap
>>> and maps. On 64 bits these are placed well separated from each other on
>>> 64 bits, so an artificial limit like this doesn't matter.
>>
>> Does the following fixup diff look reasonable? It forces
>> MAX_STACK_SIZE_MB to 1024 and hides the Kconfig option for 64BIT,
>> effectively leaving the behaviour unchanged in that case.
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index e80075979530..b0307f737bd7 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -583,7 +583,8 @@ config GENERIC_EARLY_IOREMAP
>> bool
>>
>> config MAX_STACK_SIZE_MB
>> - int "Maximum user stack size (MB)"
>> + int "Maximum user stack size (MB)" if !64BIT
>> + default 1024 if 64BIT
>> default 80
>> range 8 256 if METAG
>> range 8 2048
>
> Yes, I think that's probably correct ...
No, it's not correct.
It will then choose then a 1GB stack for compat tasks on 64bit kernel.
Helge
> parisc doesn't actually have
> anything other than a testbed 64 bit userspace, so this is a bit
> theoretical for us.
next prev parent reply other threads:[~2014-05-04 7:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 21:26 [PATCH] parisc,metag: Do not hardcode maximum userspace stack size Helge Deller
2014-04-30 21:26 ` Helge Deller
[not found] ` <20140430212602.GA20601-9U14vcwSumxwFLYp8hBm2A@public.gmane.org>
2014-04-30 22:53 ` John David Anglin
2014-04-30 22:53 ` John David Anglin
2014-05-01 11:19 ` James Hogan
2014-05-01 11:19 ` James Hogan
2014-05-01 17:50 ` James Bottomley
2014-05-02 11:54 ` James Hogan
2014-05-02 11:54 ` James Hogan
2014-05-02 14:48 ` James Bottomley
2014-05-04 7:28 ` Helge Deller [this message]
2014-05-04 7:28 ` Helge Deller
[not found] ` <5365EC05.5080900-Mmb7MZpHnFY@public.gmane.org>
2014-05-13 11:18 ` James Hogan
2014-05-13 11:18 ` James Hogan
2014-05-13 11:18 ` James Hogan
2014-05-13 19:45 ` Helge Deller
2014-05-13 22:52 ` James Hogan
2014-05-13 22:52 ` James Hogan
2014-05-01 18:08 ` Aw: " Helge Deller
2014-05-01 14:06 ` John David Anglin
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=5365EC05.5080900@gmx.de \
--to=deller-mmb7mzphnfy@public.gmane.org \
--cc=James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org \
--cc=dave.anglin-CzeTG9NwML0@public.gmane.org \
--cc=james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-parisc-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 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.