All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>
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: Fri, 2 May 2014 12:54:18 +0100	[thread overview]
Message-ID: <5363876A.2030709@imgtec.com> (raw)
In-Reply-To: <1398966636.2174.21.camel@dabdike>

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

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

Thanks
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>
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: Fri, 2 May 2014 12:54:18 +0100	[thread overview]
Message-ID: <5363876A.2030709@imgtec.com> (raw)
In-Reply-To: <1398966636.2174.21.camel@dabdike>

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

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

Thanks
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-05-02 11:54 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 [this message]
2014-05-02 11:54       ` James Hogan
2014-05-02 14:48       ` James Bottomley
2014-05-04  7:28         ` Helge Deller
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=5363876A.2030709@imgtec.com \
    --to=james.hogan@imgtec.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.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.