LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Ken Chen" <kenchen@google.com>
To: "Hugh Dickins" <hugh@veritas.com>
Cc: "Adam Litke" <agl@us.ibm.com>, "Andrew Morton" <akpm@osdl.org>,
"William Irwin" <wli@holomorphy.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Don't allow the stack to grow into hugetlb reserved regions
Date: Sun, 28 Jan 2007 12:27:48 -0800 [thread overview]
Message-ID: <b040c32a0701281227r11fe02eblba07df7aa7400787@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0701270904360.15686@blonde.wat.veritas.com>
On 1/27/07, Hugh Dickins <hugh@veritas.com> wrote:
> Thanks, that's reassuring for the hugetlb case, and therefore Adam's
> patch should not be delayed. But it does leave open the question I
> was raising in the text you've snipped: if ia64 needs those stringent
> REGION checks in its ia64_do_page_fault path, don't we need to add
> them some(messy)how in the get_user_pages find_extend_vma path?
I left it out because I need more time to digest what you said. After
looked through ia64's page fault and get_user_pages, I've concluded
that the bug scenario Adam described is impossible to trigger on ia64
due to various constrains and how the virtual address is laid out.
For ia64, the hugetlb address region is reserved at the top of user
space address. Stacks are below that region. Throw in the mix, we
have two stacks, one memory stack that grows down and one register
stack backing store that grows up. These two stacks are always in
pair and grow towards each other. And lastly, we have virtual address
holes in between regions. It's just impossible to grow any of these
two stacks into hugetlb region no matter how I played it.
So, AFAICS this bug doesn't apply to ia64 (and certainly not x86). The
new check of is_hugepage_only_range() is really a noop for both arches.
- Ken
next prev parent reply other threads:[~2007-01-28 20:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 21:40 Adam Litke
2007-01-26 20:05 ` Andrew Morton
2007-01-26 21:02 ` Hugh Dickins
2007-01-26 22:48 ` Ken Chen
2007-01-27 9:08 ` Hugh Dickins
2007-01-28 20:27 ` Ken Chen [this message]
2007-01-29 17:26 ` Hugh Dickins
2007-01-29 18:32 ` Ken Chen
2007-01-29 18:34 Adam Litke
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=b040c32a0701281227r11fe02eblba07df7aa7400787@mail.gmail.com \
--to=kenchen@google.com \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=david@gibson.dropbear.id.au \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wli@holomorphy.com \
--subject='Re: [PATCH] Don'\''t allow the stack to grow into hugetlb reserved regions' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).