[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b040c32a0701281227r11fe02eblba07df7aa7400787@mail.gmail.com>
Date: Sun, 28 Jan 2007 12:27:48 -0800
From: "Ken Chen" <kenchen@...gle.com>
To: "Hugh Dickins" <hugh@...itas.com>
Cc: "Adam Litke" <agl@...ibm.com>, "Andrew Morton" <akpm@...l.org>,
"William Irwin" <wli@...omorphy.com>,
"David Gibson" <david@...son.dropbear.id.au>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Don't allow the stack to grow into hugetlb reserved regions
On 1/27/07, Hugh Dickins <hugh@...itas.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists