From: Gustavo Romero <gromero@linux.vnet.ibm.com>
To: mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org
Subject: [RFC] Fix si->si_code for guard page access on PowerPC
Date: Fri, 22 Jan 2016 14:23:31 -0200 [thread overview]
Message-ID: <56A25783.7040502@linux.vnet.ibm.com> (raw)
Fix si->si_code for guard page access on PowerPC
Currently, the mm code on PowerPC/POWER returns a si->si_code = 2
(SEGV_ACCERR) when the stack tries to grow beyond the stack guard
(stack ulimit). On other architectures, notably x86, the si->si_code
returned when a guard page access occurs is 1 (SEGV_MAPERR).
Although si->si_code is not historically reliable and hence no
program should trust it for any semantic behavior, the right
si->si_code for a guard page access is 1 (SEGV_MAPERR) and,
besides that, some tests still trust it in specific cases.
On PowerPC/POWER, if the mm tries to expand the stack and
hits a page mapped by the program (say, an anonymous page
with permission ---p) it generates a SIG_SEGV and a si->si_code = 2
(SEGV_ACCERR), the same way it happens on x86. But then, when this
guard page is removed (un-mapped) and the stack grows again reaching
the stack guard (stack ulimit), the mm generates a SIG_SEGV and a
si->si_code = 2 (SEGV_ACCERR) again, contrary to, for example,
what happens on x86 (si->si_code = 1 (SIG_MAPERR)). It means that
on PowerPC/POWER there is no semantic difference between a stack
growth hitting a mapped area the stack has no permission to rd/wr
and reaching the stack limit (stack ulimit), although indeed there
is a difference.
Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
---
arch/powerpc/mm/fault.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index a67c6d7..6954971 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -431,8 +431,10 @@ good_area:
*/
fault = handle_mm_fault(mm, vma, address, flags);
if (unlikely(fault & (VM_FAULT_RETRY|VM_FAULT_ERROR))) {
- if (fault & VM_FAULT_SIGSEGV)
+ if (fault & VM_FAULT_SIGSEGV) {
+ code = SEGV_MAPERR;
goto bad_area;
+ }
rc = mm_fault_error(regs, address, fault);
if (rc >= MM_FAULT_RETURN)
goto bail;
next reply other threads:[~2016-01-22 16:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 16:23 Gustavo Romero [this message]
2016-02-24 9:39 ` [RFC] Fix si->si_code for guard page access on PowerPC Michael Ellerman
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=56A25783.7040502@linux.vnet.ibm.com \
--to=gromero@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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.