[{"id":1790039,"web_url":"http://patchwork.ozlabs.org/comment/1790039/","msgid":"<20171019102752.7d9075ec@MiWiFi-R3-srv>","date":"2017-10-18T23:27:52","subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","submitter":{"id":9347,"url":"http://patchwork.ozlabs.org/api/people/9347/","name":"Balbir Singh","email":"bsingharora@gmail.com"},"content":"On Fri, 8 Sep 2017 15:45:08 -0700\nRam Pai wrote:\n\n> Handle Data and Instruction exceptions caused by memory\n> protection-key.\n> \n> The CPU will detect the key fault if the HPTE is already\n> programmed with the key.\n> \n> However if the HPTE is not hashed, a key fault will not\n> be detected by the hardware. The software will detect\n> pkey violation in such a case.\n\n\nThis bit is not clear.\n\n> \n> Signed-off-by: Ram Pai \n> ---\n> arch/powerpc/mm/fault.c | 37 ++++++++++++++++++++++++++++++++-----\n> 1 files changed, 32 insertions(+), 5 deletions(-)\n> \n> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c\n> index 4797d08..a16bc43 100644\n> --- a/arch/powerpc/mm/fault.c\n> +++ b/arch/powerpc/mm/fault.c\n> @@ -145,6 +145,23 @@ static noinline int bad_area(struct pt_regs *regs, unsigned long address)\n> \treturn __bad_area(regs, address, SEGV_MAPERR);\n> }\n> \n> +static int bad_page_fault_exception(struct pt_regs *regs, unsigned long address,\n> +\t\t\t\t\tint si_code)\n> +{\n> +\tint sig = SIGBUS;\n> +\tint code = BUS_OBJERR;\n> +\n> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS\n> +\tif (si_code & DSISR_KEYFAULT) {\n> +\t\tsig = SIGSEGV;\n> +\t\tcode = SEGV_PKUERR;\n> +\t}\n> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */\n> +\n> +\t_exception(sig, regs, code, address);\n> +\treturn 0;\n> +}\n> +\n> static int do_sigbus(struct pt_regs *regs, unsigned long address,\n> \t\t unsigned int fault)\n> {\n> @@ -391,11 +408,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> \t\treturn 0;\n> \n> \tif (unlikely(page_fault_is_bad(error_code))) {\n> -\t\tif (is_user) {\n> -\t\t\t_exception(SIGBUS, regs, BUS_OBJERR, address);\n> -\t\t\treturn 0;\n> -\t\t}\n> -\t\treturn SIGBUS;\n> +\t\tif (!is_user)\n> +\t\t\treturn SIGBUS;\n> +\t\treturn bad_page_fault_exception(regs, address, error_code);\n> \t}\n> \n> \t/* Additional sanity check(s) */\n> @@ -492,6 +507,18 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> \tif (unlikely(access_error(is_write, is_exec, vma)))\n> \t\treturn bad_area(regs, address);\n> \n> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS\n> +\tif (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,\n> +\t\t\tis_exec, 0))\n> +\t\treturn __bad_area(regs, address, SEGV_PKUERR);\n\n\nHmm.. this is for the missing entry in the HPT and software detecting the\nfault you mentioned above? Why do we need this case?\n\n> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */\n> +\n> +\n> +\t/* handle_mm_fault() needs to know if its a instruction access\n> +\t * fault.\n> +\t */\n\ncomment style\n\n> +\tif (is_exec)\n> +\t\tflags |= FAULT_FLAG_INSTRUCTION;\n> \t/*\n> \t * If for any reason at all we couldn't handle the fault,\n> \t * make sure we exit gracefully rather than endlessly redo\n\nBalbir Singh.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yHSvH4N77z9t6m\n\tfor ;\n\tThu, 19 Oct 2017 10:29:31 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yHSvH2YyfzDqN4\n\tfor ;\n\tThu, 19 Oct 2017 10:29:31 +1100 (AEDT)","from mail-pf0-x243.google.com (mail-pf0-x243.google.com\n\t[IPv6:2607:f8b0:400e:c00::243])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yHSsb6pTszDq5x\n\tfor ;\n\tThu, 19 Oct 2017 10:28:03 +1100 (AEDT)","by mail-pf0-x243.google.com with SMTP id t188so5093510pfd.10\n\tfor ;\n\tWed, 18 Oct 2017 16:28:03 -0700 (PDT)","from MiWiFi-R3-srv ([122.99.82.10])\n\tby smtp.gmail.com with ESMTPSA id\n\tk20sm23637088pfg.141.2017.10.18.16.27.57\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 18 Oct 2017 16:28:01 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"k++o520X\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"k++o520X\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c00::243; helo=mail-pf0-x243.google.com;\n\tenvelope-from=bsingharora@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"k++o520X\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=TZganwMC4rjvVWbjzh8+inKdvm5D9EFcWp8ovjvhwxQ=;\n\tb=k++o520XZmdrw6nMVnF/5BUNNLIMqc5g+MeVgLnzvK5FxcL6sckbAvnzy0FpCh7QBA\n\tatF9dlgYu841pVdEiwSdOAO4T1hVTD6xRgFV17KiXJpxXCgtA5LB23M8nMWvr7yEAW8y\n\tjKRoNFxOT3ZIvQZWR1PVWAb53UlqTIAfI/MFM1lISWvfjy6QOhV8TXwaXudkrd4+2RhU\n\tOgYuM7zJFVIIa2Ei0vIXSE+PvOFWxq+FkovVRl1coDvfqiT044RCyryt+b3Bce8qDaKF\n\tUlwAPsr8rsokKgrHLUGpT4SpgTijQmmrd0T+FuBKRLNepV8ZNEO2O+efpCFgR6FmC5t7\n\tu3IA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=TZganwMC4rjvVWbjzh8+inKdvm5D9EFcWp8ovjvhwxQ=;\n\tb=cjWAi8JqXdz6IERMTGWClAGamIatiE82pnl1fNfOIpXSNRiXo3IEoQS5zuk/7EmVho\n\tlcjaFkU7Ooj/+bl5ESEu8TXU6pBb/Dd6ZVZU+OhpPrCUAw5LW3VUhEPfzAIiZOvWC9ax\n\tr73InXZyLVmjSZmtVA3hEXVg5jxm9+o5l6uhSWWPk22dsccR/FQQFuIcl7N7F877FUdF\n\tJZKGoRL97CAMJsyTH29QaG3aUQQem9LSDe1eXT79ck6KcbpTFO6adBeFG9EeUnbf3GFQ\n\toTV1GrJnhjfGNoEmwlOrIZbAf+64G4fP3AlLu9F4griMZAftePlrFb5n4Ijkurvb9AkH\n\tuJCg==","X-Gm-Message-State":"AMCzsaVDa9PoYxkswPC7czdlrtdSLM9JnrX2PpyrgxcioD3O6ZVg/eyk\n\tyW/TnJD2W7V+a6Si8bYek38=","X-Google-Smtp-Source":"AOwi7QBMFKiWNfOwe2HLeOMwPewc08lB8elFLLaCAajNzqnGwc/hi+Ul6TNRCTEB6LA5+l0IvRuUmA==","X-Received":"by 10.99.111.5 with SMTP id k5mr15151912pgc.364.1508369281633;\n\tWed, 18 Oct 2017 16:28:01 -0700 (PDT)","Date":"Thu, 19 Oct 2017 10:27:52 +1100","From":"Balbir Singh ","To":"Ram Pai ","Subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","Message-ID":"<20171019102752.7d9075ec@MiWiFi-R3-srv>","In-Reply-To":"<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>","X-Mailer":"Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ebiederm@xmission.com, mhocko@kernel.org, paulus@samba.org,\n\taneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1790777,"web_url":"http://patchwork.ozlabs.org/comment/1790777/","msgid":"<20171019165350.GU5617@ram.oc3035372033.ibm.com>","date":"2017-10-19T16:53:50","subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","submitter":{"id":2667,"url":"http://patchwork.ozlabs.org/api/people/2667/","name":"Ram Pai","email":"linuxram@us.ibm.com"},"content":"On Thu, Oct 19, 2017 at 10:27:52AM +1100, Balbir Singh wrote:\n> On Fri, 8 Sep 2017 15:45:08 -0700\n> Ram Pai wrote:\n> \n> > Handle Data and Instruction exceptions caused by memory\n> > protection-key.\n> > \n> > The CPU will detect the key fault if the HPTE is already\n> > programmed with the key.\n> > \n> > However if the HPTE is not hashed, a key fault will not\n> > be detected by the hardware. The software will detect\n> > pkey violation in such a case.\n> \n> \n> This bit is not clear.\n> \n> > \n> > Signed-off-by: Ram Pai \n> > ---\n> > arch/powerpc/mm/fault.c | 37 ++++++++++++++++++++++++++++++++-----\n> > 1 files changed, 32 insertions(+), 5 deletions(-)\n> > \n> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c\n> > index 4797d08..a16bc43 100644\n> > --- a/arch/powerpc/mm/fault.c\n> > +++ b/arch/powerpc/mm/fault.c\n> > @@ -145,6 +145,23 @@ static noinline int bad_area(struct pt_regs *regs, unsigned long address)\n> > \treturn __bad_area(regs, address, SEGV_MAPERR);\n> > }\n> > \n> > +static int bad_page_fault_exception(struct pt_regs *regs, unsigned long address,\n> > +\t\t\t\t\tint si_code)\n> > +{\n> > +\tint sig = SIGBUS;\n> > +\tint code = BUS_OBJERR;\n> > +\n> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS\n> > +\tif (si_code & DSISR_KEYFAULT) {\n> > +\t\tsig = SIGSEGV;\n> > +\t\tcode = SEGV_PKUERR;\n> > +\t}\n> > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */\n> > +\n> > +\t_exception(sig, regs, code, address);\n> > +\treturn 0;\n> > +}\n> > +\n> > static int do_sigbus(struct pt_regs *regs, unsigned long address,\n> > \t\t unsigned int fault)\n> > {\n> > @@ -391,11 +408,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> > \t\treturn 0;\n> > \n> > \tif (unlikely(page_fault_is_bad(error_code))) {\n> > -\t\tif (is_user) {\n> > -\t\t\t_exception(SIGBUS, regs, BUS_OBJERR, address);\n> > -\t\t\treturn 0;\n> > -\t\t}\n> > -\t\treturn SIGBUS;\n> > +\t\tif (!is_user)\n> > +\t\t\treturn SIGBUS;\n> > +\t\treturn bad_page_fault_exception(regs, address, error_code);\n> > \t}\n> > \n> > \t/* Additional sanity check(s) */\n> > @@ -492,6 +507,18 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> > \tif (unlikely(access_error(is_write, is_exec, vma)))\n> > \t\treturn bad_area(regs, address);\n> > \n> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS\n> > +\tif (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,\n> > +\t\t\tis_exec, 0))\n> > +\t\treturn __bad_area(regs, address, SEGV_PKUERR);\n> \n> \n> Hmm.. this is for the missing entry in the HPT and software detecting the\n> fault you mentioned above? Why do we need this case?\n\nI thought I had put in a comment motivating the reason. Seems to have\ndisappeared. Will add it back. But here is the reason....\n\nhardware enforces key-exception only after the key is programmed into\nthe HPTE. However there is a window where the key is programmed into the\nPTE and waiting for a page fault so that it can propagate key to the\nHPTE. It is that window, during which we have to guard for key\nviolation. The above check closes that small window of vulnerability.\n\t\nRP","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yHw720qPPz9t44\n\tfor ;\n\tFri, 20 Oct 2017 03:56:14 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yHw716pvPzDqGj\n\tfor ;\n\tFri, 20 Oct 2017 03:56:13 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yHw4V45FdzDqBd\n\tfor ;\n\tFri, 20 Oct 2017 03:54:02 +1100 (AEDT)","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9JGn5bH056875\n\tfor ; Thu, 19 Oct 2017 12:53:59 -0400","from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2dpyrmgh9e-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 19 Oct 2017 12:53:59 -0400","from localhost\n\tby e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 19 Oct 2017 10:53:58 -0600","from b03cxnp08025.gho.boulder.ibm.com (9.17.130.17)\n\tby e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tThu, 19 Oct 2017 10:53:55 -0600","from b03ledav005.gho.boulder.ibm.com\n\t(b03ledav005.gho.boulder.ibm.com [9.17.130.236])\n\tby b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v9JGrtdj1049048; Thu, 19 Oct 2017 09:53:55 -0700","from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id E382BBE03E;\n\tThu, 19 Oct 2017 10:53:54 -0600 (MDT)","from ram.oc3035372033.ibm.com (unknown [9.85.176.245])\n\tby b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTPS id\n\t1AEF0BE03B; Thu, 19 Oct 2017 10:53:52 -0600 (MDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=us.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=linuxram@us.ibm.com; receiver=)","Date":"Thu, 19 Oct 2017 09:53:50 -0700","From":"Ram Pai ","To":"Balbir Singh ","Subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>\n\t<20171019102752.7d9075ec@MiWiFi-R3-srv>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171019102752.7d9075ec@MiWiFi-R3-srv>","User-Agent":"Mutt/1.5.20 (2009-12-10)","X-TM-AS-GCONF":"00","x-cbid":"17101916-0004-0000-0000-000013166D9F","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007919; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000238; SDB=6.00933457; UDB=6.00470170;\n\tIPR=6.00713745; \n\tBA=6.00005651; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017609;\n\tXFM=3.00000015; UTC=2017-10-19 16:53:57","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17101916-0005-0000-0000-0000848AA143","Message-Id":"<20171019165350.GU5617@ram.oc3035372033.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-19_08:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1710190233","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Ram Pai ","Cc":"ebiederm@xmission.com, mhocko@kernel.org, paulus@samba.org,\n\taneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1793240,"web_url":"http://patchwork.ozlabs.org/comment/1793240/","msgid":"<874lqo4kf9.fsf@concordia.ellerman.id.au>","date":"2017-10-24T15:47:38","subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Ram Pai writes:\n\n> Handle Data and Instruction exceptions caused by memory\n> protection-key.\n>\n> The CPU will detect the key fault if the HPTE is already\n> programmed with the key.\n>\n> However if the HPTE is not hashed, a key fault will not\n> be detected by the hardware. The software will detect\n> pkey violation in such a case.\n\nThat seems like the wrong trade off to me.\n\nIt means every fault has to go through arch_vma_access_permitted(),\nwhich is at least a function call in the best case, even when pkeys are\nnot in use, and/or the range in question is not protected by a key.\n\nWhy not instead just service the fault and let the hardware catch it?\n\nIf that access to a protected page is a bug then the process will\nprobably just exit, in which case who cares about the overhead of the\nextra fault.\n\nIf the access is not currently allowed, but the process wants to take\nthe signal and do something to allow it, then is the overhead of the\nextra fault going to matter vs the signal etc?\n\nI think we should just let the hardware take a 2nd fault, unless someone\ncan demonstrate a workload where the cost of that is prohibitive.\n\nOr does that not work for some reason?\n\n> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c\n> index 4797d08..a16bc43 100644\n> --- a/arch/powerpc/mm/fault.c\n> +++ b/arch/powerpc/mm/fault.c\n> @@ -391,11 +408,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> \t\treturn 0;\n> \n> \tif (unlikely(page_fault_is_bad(error_code))) {\n> -\t\tif (is_user) {\n> -\t\t\t_exception(SIGBUS, regs, BUS_OBJERR, address);\n> -\t\t\treturn 0;\n> -\t\t}\n> -\t\treturn SIGBUS;\n> +\t\tif (!is_user)\n> +\t\t\treturn SIGBUS;\n> +\t\treturn bad_page_fault_exception(regs, address, error_code);\n\nI don't see why we want to handle the key fault here.\n\nI know it's caught here at the moment, because it's in\nDSISR_BAD_FAULT_64S, but I think now that we support keys we should\nremove DSISR_KEYFAULT from DSISR_BAD_FAULT_64S.\n\nThen we should let it fall through to further down, and handle it in\naccess_error().\n\nThat way eg. the page fault accounting will work as normal etc.\n\n> @@ -492,6 +507,18 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> \tif (unlikely(access_error(is_write, is_exec, vma)))\n> \t\treturn bad_area(regs, address);\n> \n> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS\n> +\tif (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,\n> +\t\t\tis_exec, 0))\n> +\t\treturn __bad_area(regs, address, SEGV_PKUERR);\n> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */\n> +\n> +\n> +\t/* handle_mm_fault() needs to know if its a instruction access\n> +\t * fault.\n> +\t */\n> +\tif (is_exec)\n> +\t\tflags |= FAULT_FLAG_INSTRUCTION;\n\nWhat is this doing here? We already do that further up.\n\ncheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yLyR71nMzz9s7p\n\tfor ;\n\tWed, 25 Oct 2017 02:50:43 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yLyR70TM2zDrCn\n\tfor ;\n\tWed, 25 Oct 2017 02:50:43 +1100 (AEDT)","from ozlabs.org (bilbo.ozlabs.org [103.22.144.67])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yLyMk1KYGzDqmj\n\tfor ;\n\tWed, 25 Oct 2017 02:47:46 +1100 (AEDT)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3yLyMg41f8z9s7p;\n\tWed, 25 Oct 2017 02:47:43 +1100 (AEDT)"],"From":"Michael Ellerman ","To":"Ram Pai , linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","In-Reply-To":"<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>","Date":"Tue, 24 Oct 2017 17:47:38 +0200","Message-ID":"<874lqo4kf9.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ebiederm@xmission.com, linuxram@us.ibm.com, mhocko@kernel.org,\n\tpaulus@samba.org, aneesh.kumar@linux.vnet.ibm.com,\n\tbauerman@linux.vnet.ibm.com, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1793383,"web_url":"http://patchwork.ozlabs.org/comment/1793383/","msgid":"<20171024182633.GK5454@ram.oc3035372033.ibm.com>","date":"2017-10-24T18:26:33","subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","submitter":{"id":2667,"url":"http://patchwork.ozlabs.org/api/people/2667/","name":"Ram Pai","email":"linuxram@us.ibm.com"},"content":"On Tue, Oct 24, 2017 at 05:47:38PM +0200, Michael Ellerman wrote:\n> Ram Pai writes:\n> \n> > Handle Data and Instruction exceptions caused by memory\n> > protection-key.\n> >\n> > The CPU will detect the key fault if the HPTE is already\n> > programmed with the key.\n> >\n> > However if the HPTE is not hashed, a key fault will not\n> > be detected by the hardware. The software will detect\n> > pkey violation in such a case.\n> \n> That seems like the wrong trade off to me.\n> \n> It means every fault has to go through arch_vma_access_permitted(),\n> which is at least a function call in the best case, even when pkeys are\n> not in use, and/or the range in question is not protected by a key.\n> \n> Why not instead just service the fault and let the hardware catch it?\n> \n> If that access to a protected page is a bug then the process will\n> probably just exit, in which case who cares about the overhead of the\n> extra fault.\n> \n> If the access is not currently allowed, but the process wants to take\n> the signal and do something to allow it, then is the overhead of the\n> extra fault going to matter vs the signal etc?\n> \n> I think we should just let the hardware take a 2nd fault, unless someone\n> can demonstrate a workload where the cost of that is prohibitive.\n> \n> Or does that not work for some reason?\n\nIt does not work, because the arch-neutral code error-outs the fault\nwithout letting the power-specific code to page-in the faulting page.\n\nSo neither does the page gets faulted, nor does the key-fault gets \nsignalled.\n\n> \n> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c\n> > index 4797d08..a16bc43 100644\n> > --- a/arch/powerpc/mm/fault.c\n> > +++ b/arch/powerpc/mm/fault.c\n> > @@ -391,11 +408,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> > \t\treturn 0;\n> > \n> > \tif (unlikely(page_fault_is_bad(error_code))) {\n> > -\t\tif (is_user) {\n> > -\t\t\t_exception(SIGBUS, regs, BUS_OBJERR, address);\n> > -\t\t\treturn 0;\n> > -\t\t}\n> > -\t\treturn SIGBUS;\n> > +\t\tif (!is_user)\n> > +\t\t\treturn SIGBUS;\n> > +\t\treturn bad_page_fault_exception(regs, address, error_code);\n> \n> I don't see why we want to handle the key fault here.\n> \n> I know it's caught here at the moment, because it's in\n> DSISR_BAD_FAULT_64S, but I think now that we support keys we should\n> remove DSISR_KEYFAULT from DSISR_BAD_FAULT_64S.\n> \n> Then we should let it fall through to further down, and handle it in\n> access_error().\n> \n> That way eg. the page fault accounting will work as normal etc.\n\nBit tricky to do that. Will try. For one if I take out DSISR_KEYFAULT\nfrom DSISR_BAD_FAULT_64S, than the assembly code in do_hash_page() will\nnot call __do_page_fault(). We want it called, but somehow\nspecial-handle DSISR_KEYFAULT to call access_error().\n\n> \n> > @@ -492,6 +507,18 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,\n> > \tif (unlikely(access_error(is_write, is_exec, vma)))\n> > \t\treturn bad_area(regs, address);\n> > \n> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS\n> > +\tif (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,\n> > +\t\t\tis_exec, 0))\n> > +\t\treturn __bad_area(regs, address, SEGV_PKUERR);\n> > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */\n> > +\n> > +\n> > +\t/* handle_mm_fault() needs to know if its a instruction access\n> > +\t * fault.\n> > +\t */\n> > +\tif (is_exec)\n> > +\t\tflags |= FAULT_FLAG_INSTRUCTION;\n> \n> What is this doing here? We already do that further up.\n\nThe more I think of this, I find that the code can be optimized and\nremove redundancy. I am unnecessarily called arch_vma_access_permitted()\nabove, when all the hardwork anyway gets done by handle_mm_fault().\nhandle_mm_fault() anyway calls arch_vma_access_permitted().\n\nI could rather use the return value of handle_mm_fault() to signal\na key-error to the userspace.\n\nRP","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yM1xR2lbxz9s7F\n\tfor ;\n\tWed, 25 Oct 2017 05:28:43 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yM1xR08FrzDqmS\n\tfor ;\n\tWed, 25 Oct 2017 05:28:42 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yM1v96pGPzDqkp\n\tfor ;\n\tWed, 25 Oct 2017 05:26:44 +1100 (AEDT)","from pps.filterd (m0098413.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9OIP1Dj126381\n\tfor ; Tue, 24 Oct 2017 14:26:42 -0400","from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2dtahp16a9-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Tue, 24 Oct 2017 14:26:41 -0400","from localhost\n\tby e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tTue, 24 Oct 2017 12:26:41 -0600","from b03cxnp07029.gho.boulder.ibm.com (9.17.130.16)\n\tby e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tTue, 24 Oct 2017 12:26:38 -0600","from b03ledav004.gho.boulder.ibm.com\n\t(b03ledav004.gho.boulder.ibm.com [9.17.130.235])\n\tby b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v9OIQcIM9568702; Tue, 24 Oct 2017 11:26:38 -0700","from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 16BF778059;\n\tTue, 24 Oct 2017 12:26:38 -0600 (MDT)","from ram.oc3035372033.ibm.com (unknown [9.85.182.80])\n\tby b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTPS id\n\t31D8878056; Tue, 24 Oct 2017 12:26:36 -0600 (MDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=us.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=linuxram@us.ibm.com; receiver=)","Date":"Tue, 24 Oct 2017 11:26:33 -0700","From":"Ram Pai ","To":"Michael Ellerman ","Subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>\n\t<874lqo4kf9.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<874lqo4kf9.fsf@concordia.ellerman.id.au>","User-Agent":"Mutt/1.5.20 (2009-12-10)","X-TM-AS-GCONF":"00","x-cbid":"17102418-0028-0000-0000-0000088BED62","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007947; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000239; SDB=6.00935880; UDB=6.00471555;\n\tIPR=6.00716147; \n\tBA=6.00005658; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017690;\n\tXFM=3.00000015; UTC=2017-10-24 18:26:40","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17102418-0029-0000-0000-0000380FB3AD","Message-Id":"<20171024182633.GK5454@ram.oc3035372033.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-24_10:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1710240251","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Ram Pai ","Cc":"ebiederm@xmission.com, mhocko@kernel.org, paulus@samba.org,\n\taneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1795453,"web_url":"http://patchwork.ozlabs.org/comment/1795453/","msgid":"<8737622gr6.fsf@linux.vnet.ibm.com>","date":"2017-10-29T14:03:25","subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","submitter":{"id":664,"url":"http://patchwork.ozlabs.org/api/people/664/","name":"Aneesh Kumar K.V","email":"aneesh.kumar@linux.vnet.ibm.com"},"content":"Michael Ellerman writes:\n\n> Ram Pai writes:\n>\n>> Handle Data and Instruction exceptions caused by memory\n>> protection-key.\n>>\n>> The CPU will detect the key fault if the HPTE is already\n>> programmed with the key.\n>>\n>> However if the HPTE is not hashed, a key fault will not\n>> be detected by the hardware. The software will detect\n>> pkey violation in such a case.\n>\n> That seems like the wrong trade off to me.\n>\n> It means every fault has to go through arch_vma_access_permitted(),\n> which is at least a function call in the best case, even when pkeys are\n> not in use, and/or the range in question is not protected by a key.\n\nWe don't really need to call arch_vma_access_permitted() in\narch/powerpc/ do_page_fault(). Core kernel does that in\nhandle_mm_fault(). So if the first fault is a bad access handle_mm_fault\nhandle this. If it is a valid access we insert the right hash page table\nentry and then we do a wrong access, we detect that a key fault in the\nlow level hash fault handler. IIUC, the call the\narch_vma_access_permitted() from arch/powerpc/ can go away?\n\n-aneesh","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yPzrT5Xgcz9t2M\n\tfor ;\n\tMon, 30 Oct 2017 01:04:41 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yPzrT3rvNzDrcS\n\tfor ;\n\tMon, 30 Oct 2017 01:04:41 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yPzqL6RNHzDqkH\n\tfor ;\n\tMon, 30 Oct 2017 01:03:41 +1100 (AEDT)","from pps.filterd (m0098421.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9TDx95q031384\n\tfor ; Sun, 29 Oct 2017 10:03:38 -0400","from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2dvnw41ta3-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Sun, 29 Oct 2017 10:03:37 -0400","from localhost\n\tby e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from\n\t; Sun, 29 Oct 2017 14:03:36 -0000","from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197)\n\tby e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tSun, 29 Oct 2017 14:03:33 -0000","from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com\n\t[9.149.105.62])\n\tby b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v9TE3WDR27918398; Sun, 29 Oct 2017 14:03:32 GMT","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 22AA2AE057;\n\tSun, 29 Oct 2017 13:57:23 +0000 (GMT)","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id CDC9AAE04D;\n\tSun, 29 Oct 2017 13:57:18 +0000 (GMT)","from skywalker (unknown [9.80.232.74])\n\tby d06av26.portsmouth.uk.ibm.com (Postfix) with SMTP;\n\tSun, 29 Oct 2017 13:57:18 +0000 (GMT)","(nullmailer pid 22001 invoked by uid 1000);\n\tSun, 29 Oct 2017 14:03:25 -0000"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=aneesh.kumar@linux.vnet.ibm.com; receiver=)","From":"\"Aneesh Kumar K.V\" ","To":"Michael Ellerman , Ram Pai ,\n\tlinuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","In-Reply-To":"<874lqo4kf9.fsf@concordia.ellerman.id.au>","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>\n\t<874lqo4kf9.fsf@concordia.ellerman.id.au>","Date":"Sun, 29 Oct 2017 19:33:25 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-GCONF":"00","x-cbid":"17102914-0016-0000-0000-000004FB269D","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17102914-0017-0000-0000-00002836A769","Message-Id":"<8737622gr6.fsf@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-29_08:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tpriorityscore=1501\n\tmalwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0\n\tclxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0\n\tclassifier=spam adjust=0 reason=mlx scancount=1\n\tengine=8.0.1-1707230000\n\tdefinitions=main-1710290199","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linuxram@us.ibm.com, mhocko@kernel.org, paulus@samba.org,\n\tebiederm@xmission.com, bauerman@linux.vnet.ibm.com,\n\tkhandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1795572,"web_url":"http://patchwork.ozlabs.org/comment/1795572/","msgid":"<20171030003719.GC5587@ram.oc3035372033.ibm.com>","date":"2017-10-30T00:37:19","subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","submitter":{"id":2667,"url":"http://patchwork.ozlabs.org/api/people/2667/","name":"Ram Pai","email":"linuxram@us.ibm.com"},"content":"On Sun, Oct 29, 2017 at 07:33:25PM +0530, Aneesh Kumar K.V wrote:\n> Michael Ellerman writes:\n> \n> > Ram Pai writes:\n> >\n> >> Handle Data and Instruction exceptions caused by memory\n> >> protection-key.\n> >>\n> >> The CPU will detect the key fault if the HPTE is already\n> >> programmed with the key.\n> >>\n> >> However if the HPTE is not hashed, a key fault will not\n> >> be detected by the hardware. The software will detect\n> >> pkey violation in such a case.\n> >\n> > That seems like the wrong trade off to me.\n> >\n> > It means every fault has to go through arch_vma_access_permitted(),\n> > which is at least a function call in the best case, even when pkeys are\n> > not in use, and/or the range in question is not protected by a key.\n> \n> We don't really need to call arch_vma_access_permitted() in\n> arch/powerpc/ do_page_fault(). Core kernel does that in\n> handle_mm_fault(). So if the first fault is a bad access handle_mm_fault\n> handle this. If it is a valid access we insert the right hash page table\n> entry and then we do a wrong access, we detect that a key fault in the\n> low level hash fault handler. IIUC, the call the\n> arch_vma_access_permitted() from arch/powerpc/ can go away?\n\n\nYes. since handle_mm_fault() checks for key-violation, we can leverage\nthat in __do_page_fault(), instead of calling arch_vma_access_permitted().\n\nHave fixed it in the next version of patches, about to to hit the mailing\nlist this week.\n\nRP","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3yQFw703CYz9t3s\n\tfor ;\n\tMon, 30 Oct 2017 11:38:47 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3yQFw66BdkzDrcm\n\tfor ;\n\tMon, 30 Oct 2017 11:38:46 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3yQFtl2sQlzDqlM\n\tfor ;\n\tMon, 30 Oct 2017 11:37:34 +1100 (AEDT)","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv9U0YNcU133697\n\tfor ; Sun, 29 Oct 2017 20:37:30 -0400","from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2dwdxqyb04-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Sun, 29 Oct 2017 20:37:30 -0400","from localhost\n\tby e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tSun, 29 Oct 2017 18:37:30 -0600","from b03cxnp07029.gho.boulder.ibm.com (9.17.130.16)\n\tby e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tSun, 29 Oct 2017 18:37:26 -0600","from b03ledav004.gho.boulder.ibm.com\n\t(b03ledav004.gho.boulder.ibm.com [9.17.130.235])\n\tby b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v9U0bQgc9961962; Sun, 29 Oct 2017 17:37:26 -0700","from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 5ED6F78043;\n\tSun, 29 Oct 2017 18:37:26 -0600 (MDT)","from ram.oc3035372033.ibm.com (unknown [9.85.185.28])\n\tby b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTPS id\n\t5354F7803F; Sun, 29 Oct 2017 18:37:23 -0600 (MDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=us.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=linuxram@us.ibm.com; receiver=)","Date":"Sun, 29 Oct 2017 17:37:19 -0700","From":"Ram Pai ","To":"\"Aneesh Kumar K.V\" ","Subject":"Re: [PATCH 20/25] powerpc: Handle exceptions caused by pkey\n\tviolation","References":"<1504910713-7094-1-git-send-email-linuxram@us.ibm.com>\n\t<1504910713-7094-29-git-send-email-linuxram@us.ibm.com>\n\t<874lqo4kf9.fsf@concordia.ellerman.id.au>\n\t<8737622gr6.fsf@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<8737622gr6.fsf@linux.vnet.ibm.com>","User-Agent":"Mutt/1.5.20 (2009-12-10)","X-TM-AS-GCONF":"00","x-cbid":"17103000-0028-0000-0000-00000892418B","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007976; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000239; SDB=6.00938381; UDB=6.00472998;\n\tIPR=6.00718642; \n\tBA=6.00005662; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017781;\n\tXFM=3.00000015; UTC=2017-10-30 00:37:28","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17103000-0029-0000-0000-00003821DD1E","Message-Id":"<20171030003719.GC5587@ram.oc3035372033.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-29_12:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tpriorityscore=1501\n\tmalwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0\n\tclxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0\n\tclassifier=spam adjust=0 reason=mlx scancount=1\n\tengine=8.0.1-1707230000\n\tdefinitions=main-1710300005","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"Ram Pai ","Cc":"mhocko@kernel.org, paulus@samba.org, ebiederm@xmission.com,\n\tbauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,\n\tkhandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]