From: Gary Hade <garyhade@us.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Gary Hade <garyhade@us.ibm.com>,
Badari Pulavarty <pbadari@us.ibm.com>,
Alex Chiang <achiang@hp.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch -mm] mm: slab allocate memory section nodemask for large systems
Date: Wed, 18 Nov 2009 10:35:24 -0800 [thread overview]
Message-ID: <20091118183523.GA7793@us.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0911171618430.25821@chino.kir.corp.google.com>
Hi David,
On Tue, Nov 17, 2009 at 04:19:30PM -0800, David Rientjes wrote:
> Nodemasks should not be allocated on the stack for large systems (when it
> is larger than 256 bytes) since there is a threat of overflow.
>
> This patch causes the unregister_mem_sect_under_nodes() nodemask to be
> allocated on the stack for smaller systems and be allocated by slab for
> larger systems.
I notice that there are many other functions that always allocate
nodemask_t objects on the stack. In addition to several that add
a single instance to the stack, cpuset_attach() in kernel/cpuset.c
adds 2 instances and all that are created by using SYSCALL_DEFINE4()
in mm/mempolicy.c add 3 instances. Are there plans to correct the
other functions as well or is there something about
unregister_mem_sect_under_nodes() that makes it more likely to
cause stack overflows than the others?
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc
next prev parent reply other threads:[~2009-11-18 18:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 0:19 [patch -mm] mm: slab allocate memory section nodemask for large systems David Rientjes
2009-11-18 18:35 ` Gary Hade [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-10-22 4:15 [PATCH v2 0/5] mm: modest useability enhancements for node sysfs attrs Alex Chiang
2009-10-22 4:15 ` [PATCH v2 1/5] mm: add numa node symlink for memory section in sysfs Alex Chiang
2009-10-22 19:51 ` David Rientjes
2009-10-27 19:59 ` Alex Chiang
2009-10-27 21:27 ` David Rientjes
2009-10-28 8:31 ` Heiko Carstens
2009-10-28 9:03 ` David Rientjes
2009-10-28 18:39 ` Alex Chiang
2009-10-28 20:43 ` [patch -mm] mm: slab allocate memory section nodemask for large systems David Rientjes
2009-10-28 20:43 ` David Rientjes
2009-11-02 20:47 ` Alex Chiang
2009-11-02 20:47 ` Alex Chiang
2009-11-04 2:00 ` David Rientjes
2009-11-04 2:00 ` David Rientjes
2009-11-10 20:51 ` Andrew Morton
2009-11-10 20:51 ` Andrew Morton
2009-11-10 20:55 ` David Rientjes
2009-11-10 20:55 ` David Rientjes
2009-11-10 21:26 ` Alex Chiang
2009-11-10 21:26 ` Alex Chiang
2009-11-10 21:38 ` Andrew Morton
2009-11-10 21:38 ` Andrew Morton
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=20091118183523.GA7793@us.ibm.com \
--to=garyhade@us.ibm.com \
--cc=achiang@hp.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
--cc=rientjes@google.com \
/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.