From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Hugh Dickins <hughd@google.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Shaohua Li <shaohua.li@intel.com>, Michal Hocko <mhocko@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, kosaki.motohiro@gmail.com
Subject: Re: [PATCH] fix bug introduced in "mm: simplify find_vma_prev()"
Date: Tue, 06 Mar 2012 19:30:25 -0500 [thread overview]
Message-ID: <4F56AC21.1050000@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1203041946430.3487@file.rdu.redhat.com>
(3/4/12 7:52 PM), Mikulas Patocka wrote:
> Hi
>
> This patch fixes a bug introduced in "mm: simplify find_vma_prev()". You
> can apply this, or alternatively revert the original patch.
>
> Mikulas
>
> ---
>
> mm: fix find_vma_prev
>
> The commit mm: simplify find_vma_prev()
> [6bd4837de96e7d9f9bf33e59117c24fc230862ac] broke memory management on PA-RISC.
>
> After application of the patch, programs that allocate big arrays on the stack
> crash with segfault, for example, this will crash if compiled without
> optimization:
> int main()
> {
> char array[200000];
> array[199999] = 0;
> return 0;
> }
>
> The reason is that PA-RISC has up-growing stack and the stack is usually the
> last memory area. In the above example, a page fault happens above the stack.
>
> Previously, if we passed too high address to find_vma_prev, it returned NULL
> and stored the last VMA in *pprev. After "simplify find_vma_prev" change, it
> stores NULL in *pprev. Consequently, the stack area is not found and it is
> not expanded, as it used to be before the change.
>
> This patch restores the old behavior and makes it return the last VMA in *pprev
> if the requested address is higher than address of any other VMA.
>
> Signed-off-by: Mikulas Patocka<mpatocka@redhat.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
I prefer to remove find_vma_prev() eventually. but this is good short term solution.
next prev parent reply other threads:[~2012-03-07 0:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 0:52 [PATCH] fix bug introduced in "mm: simplify find_vma_prev()" Mikulas Patocka
2012-03-05 1:22 ` Linus Torvalds
2012-03-06 18:57 ` Mikulas Patocka
2012-03-07 0:27 ` KOSAKI Motohiro
2012-03-07 0:30 ` KOSAKI Motohiro [this message]
2012-03-07 2:27 ` Linus Torvalds
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=4F56AC21.1050000@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
--cc=mpatocka@redhat.com \
--cc=shaohua.li@intel.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox