From patchwork Fri Jan 22 16:23:31 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gustavo Romero X-Patchwork-Id: 571832 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 634A214031E for ; Sat, 23 Jan 2016 09:58:44 +1100 (AEDT) Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 489E41A188B for ; Sat, 23 Jan 2016 09:58:44 +1100 (AEDT) X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Received: from e24smtp02.br.ibm.com (e24smtp02.br.ibm.com [32.104.18.86]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 44BAD1A0019 for ; Sat, 23 Jan 2016 03:23:42 +1100 (AEDT) Received: from localhost by e24smtp02.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 22 Jan 2016 14:23:37 -0200 Received: from d24dlp01.br.ibm.com (9.18.248.204) by e24smtp02.br.ibm.com (10.172.0.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 22 Jan 2016 14:23:34 -0200 X-IBM-Helo: d24dlp01.br.ibm.com X-IBM-MailFrom: gromero@linux.vnet.ibm.com X-IBM-RcptTo: linuxppc-dev@lists.ozlabs.org Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by d24dlp01.br.ibm.com (Postfix) with ESMTP id 070BF352006C for ; Fri, 22 Jan 2016 11:23:27 -0500 (EST) Received: from d24av04.br.ibm.com (d24av04.br.ibm.com [9.8.31.97]) by d24relay01.br.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0MGOAIO4763856 for ; Fri, 22 Jan 2016 14:24:11 -0200 Received: from d24av04.br.ibm.com (localhost [127.0.0.1]) by d24av04.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0MGNVFJ000370 for ; Fri, 22 Jan 2016 14:23:32 -0200 Received: from [9.18.239.185] (dhcp-9-18-239-185.br.ibm.com [9.18.239.185]) by d24av04.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0MGNV6n000365; Fri, 22 Jan 2016 14:23:31 -0200 To: mpe@ellerman.id.au From: Gustavo Romero Subject: [RFC] Fix si->si_code for guard page access on PowerPC Message-ID: <56A25783.7040502@linux.vnet.ibm.com> Date: Fri, 22 Jan 2016 14:23:31 -0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16012216-0021-0000-0000-000004C63E19 X-Mailman-Approved-At: Sat, 23 Jan 2016 09:57:50 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 --- 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;