[{"id":1765302,"web_url":"http://patchwork.ozlabs.org/comment/1765302/","msgid":"<20170908090214.vfrbqaphia46qkhs@pd.tnic>","list_archive_url":null,"date":"2017-09-08T09:02:15","subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","submitter":{"id":47897,"url":"http://patchwork.ozlabs.org/api/people/47897/","name":"Borislav Petkov","email":"bp@suse.de"},"content":"On Thu, Sep 07, 2017 at 03:45:14PM +0800, Xie XiuQi wrote:\n> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors\n> are consumed. In some cases, if the error address is in a clean page or a\n> read-only page, there is a chance to recover. Such as error occurs in a\n> instruction page, we can reread this page from disk instead of killing\n> process.\n> \n> Because memory_failure() may sleep, we can not call it directly in SEA\n> exception context. So we saved faulting physical address associated with\n> a process in the ghes handler and set __TIF_SEA_NOTIFY. When we return\n> from SEA exception context and get into do_notify_resume() before the\n> process running, we could check it and call memory_failure() to do\n> recovery. It's safe, because we are in process context.\n> \n> Signed-off-by: Xie XiuQi \n> Signed-off-by: Wang Xiongfeng \n\nThis is not a correct SOB chain, please check:\n\nDocumentation/process/submitting-patches.rst, section 11.\n\n> ---\n> arch/arm64/Kconfig | 11 +++\n> arch/arm64/include/asm/ras.h | 36 +++++++++\n> arch/arm64/include/asm/thread_info.h | 4 +-\n> arch/arm64/kernel/Makefile | 1 +\n> arch/arm64/kernel/ras.c | 141 +++++++++++++++++++++++++++++++++++\n> arch/arm64/kernel/signal.c | 8 ++\n> arch/arm64/mm/fault.c | 27 +++++--\n> drivers/acpi/apei/ghes.c | 4 +-\n> 8 files changed, 221 insertions(+), 11 deletions(-)\n> create mode 100644 arch/arm64/include/asm/ras.h\n> create mode 100644 arch/arm64/kernel/ras.c\n\nWhat tree are those patches against?\n\nThey don't apply cleanly against latest mainline:\n\nchecking file arch/arm64/Kconfig\nHunk #1 succeeded at 641 (offset 1 line).\nchecking file arch/arm64/include/asm/ras.h\nchecking file arch/arm64/include/asm/thread_info.h\nHunk #1 FAILED at 86.\nHunk #2 succeeded at 98 (offset -4 lines).\nHunk #3 FAILED at 112.\n2 out of 3 hunks FAILED\nchecking file arch/arm64/kernel/Makefile\nchecking file arch/arm64/kernel/ras.c\nchecking file arch/arm64/kernel/signal.c\nHunk #1 succeeded at 40 with fuzz 1 (offset 2 lines).\nHunk #2 FAILED at 750.\n1 out of 2 hunks FAILED\nchecking file arch/arm64/mm/fault.c\nHunk #1 succeeded at 631 (offset 37 lines).\nchecking file drivers/acpi/apei/ghes.c","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"kyW3u+/X\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpcRY1gpbz9rxl\n\tfor ;\n\tFri, 8 Sep 2017 22:42:45 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqIcM-0001tc-6T; Fri, 08 Sep 2017 12:42:42 +0000","from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de)\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqIcH-0001oF-JW for linux-arm-kernel@lists.infradead.org;\n\tFri, 08 Sep 2017 12:42:39 +0000","from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])\n\tby mx1.suse.de (Postfix) with ESMTP id 80E82AEAF;\n\tFri, 8 Sep 2017 12:42:12 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=THhzNT7UXe7kf9rfWJcr7oGDHLQU/eUxUzbHhUR7RYM=;\n\tb=kyW3u+/XhwviY2\n\tNBE6h5/+3TFKoKZfCAmkIBOiMg+zRt3cPd2mYhc6Gy/szUfpbm4+AwWoY6BaSHUgdyCjQpbRlyqAn\n\tuEB3+JMILN3H9IwdC9luylvq47RiMvpVwu0v0AkRanzsbOz9C56zUPnLdTBA9SjMsqQbWpHd/uxP5\n\tWlbMRIFXcL6TIbFtGDqiT9W3Ve2TAm1snyIGWDdu0qXy/Tp8iGyC/TIQDkULkx5GL4/73AVqqFovv\n\tkNGsgac327//g9NiJRx2H3Si3y50O0qCQUeQCi/49fIX0AA7RXPKWU9jU6AiDH2y0LN0alhwmU80X\n\tY88AJtPYKYDhYphGSNXA==;","X-Virus-Scanned":"by amavisd-new at test-mx.suse.de","Date":"Fri, 8 Sep 2017 11:02:15 +0200","From":"Borislav Petkov ","To":"Xie XiuQi ","Subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","Message-ID":"<20170908090214.vfrbqaphia46qkhs@pd.tnic>","References":"<1504770316-4327-1-git-send-email-xiexiuqi@huawei.com>\n\t<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170908_054237_807289_E2A85656 ","X-CRM114-Status":"GOOD ( 13.91 )","X-Spam-Score":"-2.6 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.6 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\n\tmedium trust [195.135.220.15 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t1.6 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, wangkefeng.wang@huawei.com, cj.chengjian@huawei.com,\n\tjulien.thierry@arm.com, catalin.marinas@arm.com,\n\tstephen.boyd@linaro.org, \n\twill.deacon@arm.com, lijinyue@huawei.com, huawei.libin@huawei.com,\n\tguohanjun@huawei.com, wangxiongfeng2@huawei.com,\n\ttakahiro.akashi@linaro.org, \n\tzjzhang@codeaurora.org, gengdongjiu@huawei.com,\n\tlinux-acpi@vger.kernel.org, \n\tmingo@redhat.com, Dave.Martin@arm.com, tbaicar@codeaurora.org,\n\tzhengqiang10@huawei.com, linux-arm-kernel@lists.infradead.org,\n\tard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org,\n\tjames.morse@arm.com, shiju.jose@huawei.com","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1765565,"web_url":"http://patchwork.ozlabs.org/comment/1765565/","msgid":"<59B2DE26.4060002@arm.com>","list_archive_url":null,"date":"2017-09-08T18:15:02","subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","submitter":{"id":66575,"url":"http://patchwork.ozlabs.org/api/people/66575/","name":"James Morse","email":"james.morse@arm.com"},"content":"Hi Xie XiuQi,\n\n(Sorry a few versions of this went past before I caught up with it)\n\nOn 07/09/17 08:45, Xie XiuQi wrote:\n> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors\n> are consumed. In some cases, if the error address is in a clean page or a\n> read-only page, there is a chance to recover. Such as error occurs in a\n> instruction page, we can reread this page from disk instead of killing\n> process.\n\n> Because memory_failure() may sleep, we can not call it directly in SEA\n> exception context.\n\nThis is why we have memory_failure_queue() instead, it ... bother. That doesn't\nlook nmi-safe. (I thought this ended with an llist, but clearly I was looking at\nthe wrong thing).\n\nIt doesn't look like this is a problem for NOTIFY_SEA as it would only interrupt\nitself on the same CPU if the memory-failure code/data were corrupt. (which is\nnot a case we can handle). We need to fix this before any of the asynchronous\nNMI-like RAS notifications for arm64 get merged.\n\n(this is one problem, but I don't think its 'the' problem you are trying to\nsolve with this series).\n\n\n> So we saved faulting physical address associated with\n> a process in the ghes handler and set __TIF_SEA_NOTIFY.\n\nA per-notification type TIF flag looks fishy, surely this would affect all\nNMI-like RAS notification methods?\n\n\n> When we return\n> from SEA exception context and get into do_notify_resume() before the\n> process running, we could check it and call memory_failure() to do\n> recovery. It's safe, because we are in process context.\n\nI'm afraid I don't think this is the best approach for fixing this.\nIts tied to the notification type, but the notification should be irrelevant\nonce we call ghes_proc().\nIt adds code poking around in CPER and ACPI/GHES to the arm64 arch code, all of\nthis should be in the core common code.\nMost importantly: this means arm64 behaves differently with regard to handling\nmemory errors to other architectures using ACPI. Two behaviours means twice the\ncode, review and bugs...\n\n\nDelaying the handling until we re-enter user-space means faults that may affect\nthe kernel aren't handled until much later. Just because the fault was\nsynchronous and user-space was running doesn't mean only user space is affected.\nSome examples I've collected so far: the zero-page may be corrupt, this is\nmapped into every process and used by the kernel. Similarly corruption in the\nvdso affects all user-space. The fault may affect the page tables, this affects\nall users of the mm_struct.\n\n(I'm sure we agree that an synchronous-external-abort interrupting the kernel is\nfatal for the kernel, but the other way round isn't always true).\n\nSetting a TIF flag to handle the error before re-entering user-space is a\nproblem as the scheduler may choose to pre-empt this task and run all the other\ntasks before this eventually gets handled.\n\n\nAssuming this is just a problem with memory_failure_queue(), two alternatives I\ncan suggest are making memory_failure_queue() nmi-safe, or abstracting\nNOTIFY_NMI's estatus pool/cache to use for the arm64 NMI-like notifications too.\n\nIf there is more to this, can you explain the problem you're trying to solve?\n(I suspect there may be an issue with multiple-signals being merged, or exactly\nwhen memory_failure_queue()'s work gets run.) Can you outline the sequence of\nevents?\n\n\nYou're picking a physical address out of 'ARM Processor Error Information\nStructure', these correspond with Cache, TLB, Bus or (the mysterious) 'micro\narchitectural error'. I don't see anything checking the error type.\nGiven the physical address, are you adding error-handling for cache-errors with\nthis series?\n\n\nThanks,\n\nJames","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"UU4lIwDB\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpls82vn3z9sDB\n\tfor ;\n\tSat, 9 Sep 2017 04:16:59 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqNpo-0000hS-RE; Fri, 08 Sep 2017 18:16:56 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqNpl-0000b8-9u for linux-arm-kernel@lists.infradead.org;\n\tFri, 08 Sep 2017 18:16:54 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CEC4813D5;\n\tFri, 8 Sep 2017 11:16:31 -0700 (PDT)","from [10.1.207.55] (melchizedek.cambridge.arm.com [10.1.207.55])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t46A463F540; Fri, 8 Sep 2017 11:16:26 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Subject:To:\n\tMIME-Version:From:Date:Message-ID:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=PdZRElnP7Gg8VKRTg7gFbEZ4wbynh23zIuEN8MP/ZdY=;\n\tb=UU4lIwDBkxzSov\n\tzF45vHK3mRmygihguDL0ZdlA820299yoIrBVqjAR2T5tEMaQWG4GmMZkZ0F6u3k1lVCtXicHX/v8X\n\tSHfJlOgiTvh2VF1B5BgkOe+ZdkAG++mkZ1tPRHXvjBQb1jZf+vCqJDcGpSRF/0krZW6BeRWP8ZpRf\n\tvuh6iz5yIlV4CK1nBqMvzukgzU5EqCDefObO6Dn9m45yAK4dLMsJpycECkD1WmDyqGlHzU3nj9H+2\n\tJRGXbG6RJlgts0ij3c+ZWu0Ou9thucAV73RZHy8RtzHFIEEij2Jgj/Aflyancbjxwr3WHoc+TT3vh\n\tNczIWpXAd8T9UupG6wyQ==;","Message-ID":"<59B2DE26.4060002@arm.com>","Date":"Fri, 08 Sep 2017 19:15:02 +0100","From":"James Morse ","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:31.0) Gecko/20100101 Icedove/31.6.0","MIME-Version":"1.0","To":"Xie XiuQi ","Subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","References":"<1504770316-4327-1-git-send-email-xiexiuqi@huawei.com>\n\t<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>","In-Reply-To":"<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170908_111653_374123_5353CD50 ","X-CRM114-Status":"GOOD ( 19.48 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, wangkefeng.wang@huawei.com, cj.chengjian@huawei.com,\n\tjulien.thierry@arm.com, catalin.marinas@arm.com,\n\tstephen.boyd@linaro.org, \n\twill.deacon@arm.com, lijinyue@huawei.com, huawei.libin@huawei.com,\n\tguohanjun@huawei.com, wangxiongfeng2@huawei.com,\n\ttakahiro.akashi@linaro.org, \n\tzjzhang@codeaurora.org, gengdongjiu@huawei.com,\n\tlinux-acpi@vger.kernel.org, \n\tmingo@redhat.com, bp@suse.de, Dave.Martin@arm.com,\n\ttbaicar@codeaurora.org, \n\tzhengqiang10@huawei.com, linux-arm-kernel@lists.infradead.org,\n\tard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org,\n\tshiju.jose@huawei.com","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1766030,"web_url":"http://patchwork.ozlabs.org/comment/1766030/","msgid":"<8de27b1f-3bc7-93cf-fde7-6157c6957dd5@huawei.com>","list_archive_url":null,"date":"2017-09-11T01:56:59","subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","submitter":{"id":72343,"url":"http://patchwork.ozlabs.org/api/people/72343/","name":"Xiongfeng Wang","email":"wangxiongfeng2@huawei.com"},"content":"Hi James,\n\nThanks for your comments.\n\nOn 2017/9/9 2:15, James Morse wrote:\n> Hi Xie XiuQi,\n> \n> (Sorry a few versions of this went past before I caught up with it)\n> \n> On 07/09/17 08:45, Xie XiuQi wrote:\n>> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors\n>> are consumed. In some cases, if the error address is in a clean page or a\n>> read-only page, there is a chance to recover. Such as error occurs in a\n>> instruction page, we can reread this page from disk instead of killing\n>> process.\n> \n>> Because memory_failure() may sleep, we can not call it directly in SEA\n>> exception context.\n> \n> This is why we have memory_failure_queue() instead, it ... bother. That doesn't\n> look nmi-safe. (I thought this ended with an llist, but clearly I was looking at\n> the wrong thing).\n> \n> It doesn't look like this is a problem for NOTIFY_SEA as it would only interrupt\n> itself on the same CPU if the memory-failure code/data were corrupt. (which is\n> not a case we can handle). We need to fix this before any of the asynchronous\n> NMI-like RAS notifications for arm64 get merged.\n> \n> (this is one problem, but I don't think its 'the' problem you are trying to\n> solve with this series).\n> \n> \n>> So we saved faulting physical address associated with\n>> a process in the ghes handler and set __TIF_SEA_NOTIFY.\n> \n> A per-notification type TIF flag looks fishy, surely this would affect all\n> NMI-like RAS notification methods?\n> \n> \n>> When we return\n>> from SEA exception context and get into do_notify_resume() before the\n>> process running, we could check it and call memory_failure() to do\n>> recovery. It's safe, because we are in process context.\n> \n> I'm afraid I don't think this is the best approach for fixing this.\n> Its tied to the notification type, but the notification should be irrelevant\n> once we call ghes_proc().\n> It adds code poking around in CPER and ACPI/GHES to the arm64 arch code, all of\n> this should be in the core common code.\n> Most importantly: this means arm64 behaves differently with regard to handling\n> memory errors to other architectures using ACPI. Two behaviours means twice the\n> code, review and bugs...\n\nI think we can use arch_apei_report_mem_error() to report memory error, just like\nwhat is implemented in x86. We can record the memory address in somewhere else, namely\nreport the error. Then the SEA handler can use the memory error reported.\n\n> \n> \n> Delaying the handling until we re-enter user-space means faults that may affect\n> the kernel aren't handled until much later. Just because the fault was\n> synchronous and user-space was running doesn't mean only user space is affected.\n> Some examples I've collected so far: the zero-page may be corrupt, this is\n> mapped into every process and used by the kernel. Similarly corruption in the\n> vdso affects all user-space. The fault may affect the page tables, this affects\n> all users of the mm_struct.\n\nI am not sure if memory_failure can recognize the zero page as a kernel page and\njust panic. If several processes share a same page, I think we don't have to kill\nthe process until it access the address containing the errors. If the process access\nthe error address, a SEA will occur again, then we can handle it. If the process\nwill never access the error address, such as a syscall in vdso the process won't use,\nwe don't have to kill the process.\n\nFor vdso case, we havn't repaired the error. It will affect newly created processes.\nI don't figure out how to handle this. Is it a kernel page mapped into user space\nor memory_failure will just panic when handling this page.\n\n> \n> (I'm sure we agree that an synchronous-external-abort interrupting the kernel is\n> fatal for the kernel, but the other way round isn't always true).\n> \n> Setting a TIF flag to handle the error before re-entering user-space is a\n> problem as the scheduler may choose to pre-empt this task and run all the other\n> tasks before this eventually gets handled.\n> \n> \n> Assuming this is just a problem with memory_failure_queue(), two alternatives I\n> can suggest are making memory_failure_queue() nmi-safe,\nYes, I agree, but it may be hard to be achieved.\n\n or abstracting\n> NOTIFY_NMI's estatus pool/cache to use for the arm64 NMI-like notifications too.\n> \n> If there is more to this, can you explain the problem you're trying to solve?\n> (I suspect there may be an issue with multiple-signals being merged, or exactly\n> when memory_failure_queue()'s work gets run.) Can you outline the sequence of\n> events?\n> \n> \n> You're picking a physical address out of 'ARM Processor Error Information\n> Structure', these correspond with Cache, TLB, Bus or (the mysterious) 'micro\n> architectural error'. I don't see anything checking the error type.\n> Given the physical address, are you adding error-handling for cache-errors with\n> this series?\n> \n> \n> Thanks,\n> \n> James\n> \n> \n> .\n> \n\nThanks,\n\nXiongfeng Wang","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"FDT5hMUg\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrB0T16YJz9s7g\n\tfor ;\n\tMon, 11 Sep 2017 11:58:17 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1drDzE-0003Mc-0p; Mon, 11 Sep 2017 01:58:08 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1drDzA-0003G9-4M for linux-arm-kernel@lists.infradead.org;\n\tMon, 11 Sep 2017 01:58:06 +0000","from 172.30.72.58 (EHLO DGGEMS414-HUB.china.huawei.com)\n\t([172.30.72.58])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHB13254; Mon, 11 Sep 2017 09:57:09 +0800 (CST)","from [127.0.0.1] (10.177.32.209) by DGGEMS414-HUB.china.huawei.com\n\t(10.3.19.214) with Microsoft SMTP Server id 14.3.301.0;\n\tMon, 11 Sep 2017 09:57:02 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=rvggYmcrMM9c6WDjhg6iucp9GMgohxxVvAhp4gwNYRI=;\n\tb=FDT5hMUgr/bBms\n\tvN39afmzv6epr3GpDBd6sWmtKUPYb1OIgFjxP8x+qL2x9AiFeWe7Kdvtj0uMzvP7r2qaBjJKQBgxK\n\tc9LYiM6+Vos6A672EATFNis6s31hE7W1uJNpIqj+oTrv9ieuZBi04nD1OZ2/wM3u0F0Qg4ZklLNoV\n\toPFUYSliOCfFdmHiosm9L4WLH6g7Ak04Lgoxl9etvpMqN+/5eZDiuP87AbBhiYe91EoXAcugWs0uC\n\tPEaBIduiMNIkT8FAVINTO0ZWuoJjl93ol1eKGNHGO5iy827WujOYiIBHFDNJITRfv1KnfSrRj2tdo\n\tUnscP/zy34GO8XDEOL/A==;","Subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","To":"James Morse , Xie XiuQi ","References":"<1504770316-4327-1-git-send-email-xiexiuqi@huawei.com>\n\t<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>\n\t<59B2DE26.4060002@arm.com>","From":"Xiongfeng Wang ","Message-ID":"<8de27b1f-3bc7-93cf-fde7-6157c6957dd5@huawei.com>","Date":"Mon, 11 Sep 2017 09:56:59 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.2.0","MIME-Version":"1.0","In-Reply-To":"<59B2DE26.4060002@arm.com>","X-Originating-IP":"[10.177.32.209]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020205.59B5ED76.00A1, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"e3d7d82c6511f5bbcd79035cd3bc61a9","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170910_185804_721662_3345CC77 ","X-CRM114-Status":"GOOD ( 28.90 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, wangkefeng.wang@huawei.com, cj.chengjian@huawei.com,\n\tjulien.thierry@arm.com, catalin.marinas@arm.com,\n\tstephen.boyd@linaro.org, \n\twill.deacon@arm.com, lijinyue@huawei.com, huawei.libin@huawei.com,\n\tguohanjun@huawei.com, takahiro.akashi@linaro.org,\n\tzjzhang@codeaurora.org, \n\tgengdongjiu@huawei.com, linux-acpi@vger.kernel.org, mingo@redhat.com, \n\tbp@suse.de, Dave.Martin@arm.com, tbaicar@codeaurora.org,\n\tzhengqiang10@huawei.com, linux-arm-kernel@lists.infradead.org,\n\tard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org,\n\tshiju.jose@huawei.com","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1766326,"web_url":"http://patchwork.ozlabs.org/comment/1766326/","msgid":"<52d2868c-79cd-8ff8-8e1d-6078d02d5a0c@huawei.com>","list_archive_url":null,"date":"2017-09-11T14:11:26","subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","submitter":{"id":24815,"url":"http://patchwork.ozlabs.org/api/people/24815/","name":"Xie XiuQi","email":"xiexiuqi@huawei.com"},"content":"Hi James,\n\nThank you very much for your carefully review.\n\nI first describe the approach of this patchset:\n\nA memory access error on the execution path usually triggers SEA.\nAccording to the existing process, errors occurred in the kernel,\nleading to direct panic, if it occurred the user-space, we should\njust kill process.\n\nBut there is a class of error, in fact, is not necessary to kill\nprocess, you can recover and continue to run the process. Such as\nthe instruction data corrupted, where the memory page might be\nread-only, which is has not been modified, the disk might have the\ncorrect data, so you can directly drop the page, ant reload it when\nnecessary.\n\nSo this patchset is just try to solve such problem: if the error is\nconsumed in user-space and the error occurs on a clean page, you can\ndirectly drop the memory page without killing process.\n\nThis is implemented in memory_failure, which is generic process.\n\nmemory_failure\n -> hwpoison_user_mappings\n\n\t/*\n\t * Propagate the dirty bit from PTEs to struct page first, because we\n\t * need this to decide if we should kill or just drop the page.\n\t * XXX: the dirty test could be racy: set_page_dirty() may not always\n\t * be called inside page lock (it's recommended but not enforced).\n\t */\n\tmapping = page_mapping(hpage);\n\tif (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&\n\t mapping_cap_writeback_dirty(mapping)) {\n\t\tif (page_mkclean(hpage)) {\n\t\t\tSetPageDirty(hpage);\n\t\t} else {\n\t\t\tkill = 0;\n\t\t\tttu |= TTU_IGNORE_HWPOISON;\n\t\t\tpr_info(\"Memory failure: %#lx: corrupted page was clean: dropped without side effects\\n\",\n\t\t\t\tpfn);\n\t\t}\n\t}\n\nThe error reported by SEA should be handled before re-enter the process,\nor we must kill the process to prevent error propagation.\n\nmemory_failure_queue() is asynchronous, in which, error info was saved\nat ghes_proc, but handled in kworker. During this period there is a context\nswitching, so we can not determine which process would be switch to. So\nmemory_failure_queue is not suitable for handling the problem.\n\nAnd memory_failure is not nmi-safe, so it can not be called directly in the\nSEA context. So we just handle this error at SEA exit path, and before context\nswitching.\n\nIn FFH mode, physical address can only be obtained by parsing the GHES table.\nBut we only care about SEA, so the error handling is tied to the type of notification.\n\nThe TIF flag is checked on a generic path, but it will only be set when SEA occurs.\nAnd if we use unlikely optimization, it should have little impact on performance.\n\nAnd the TIF flag approach was used on x86 platform for years, until commit d4812e169d\n(x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks)[0]. On currently arm64\nplatform, there is no IST interrupt[1] function, so we could not call memory_failure\ndirectly in SEA context. So the way to use TIF notification, is also a good choice,\nafter all, the same way on x86 platform is verified.\n\nAny comment is welcome, thanks.\n\n[0] https://patchwork.kernel.org/patch/5571021/\n[1] [PATCH v4 0/5] x86: Rework IST interrupts https://lkml.org/lkml/2014/11/21/632\n\nOn 2017/9/9 2:15, James Morse wrote:\n> Hi Xie XiuQi,\n> \n> (Sorry a few versions of this went past before I caught up with it)\n> \n> On 07/09/17 08:45, Xie XiuQi wrote:\n>> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors\n>> are consumed. In some cases, if the error address is in a clean page or a\n>> read-only page, there is a chance to recover. Such as error occurs in a\n>> instruction page, we can reread this page from disk instead of killing\n>> process.\n> \n>> Because memory_failure() may sleep, we can not call it directly in SEA\n>> exception context.\n> \n> This is why we have memory_failure_queue() instead, it ... bother. That doesn't\n> look nmi-safe. (I thought this ended with an llist, but clearly I was looking at\n> the wrong thing).\n> \n> It doesn't look like this is a problem for NOTIFY_SEA as it would only interrupt\n> itself on the same CPU if the memory-failure code/data were corrupt. (which is\n> not a case we can handle). We need to fix this before any of the asynchronous\n> NMI-like RAS notifications for arm64 get merged.\n> \n> (this is one problem, but I don't think its 'the' problem you are trying to\n> solve with this series).\n> \n> \n>> So we saved faulting physical address associated with\n>> a process in the ghes handler and set __TIF_SEA_NOTIFY.\n> \n> A per-notification type TIF flag looks fishy, surely this would affect all\n> NMI-like RAS notification methods?\n> \n> \n>> When we return\n>> from SEA exception context and get into do_notify_resume() before the\n>> process running, we could check it and call memory_failure() to do\n>> recovery. It's safe, because we are in process context.\n> \n> I'm afraid I don't think this is the best approach for fixing this.\n> Its tied to the notification type, but the notification should be irrelevant\n> once we call ghes_proc().\n> It adds code poking around in CPER and ACPI/GHES to the arm64 arch code, all of\n> this should be in the core common code.\n> Most importantly: this means arm64 behaves differently with regard to handling\n> memory errors to other architectures using ACPI. Two behaviours means twice the\n> code, review and bugs...\n\nYes, I agree.\n\nI try to avoid the introduction of architecture-related code in CPER and ACPI / GHES,\nbut CPER_SEC_PROC_ARM is ARM specific, so if you want to do some recovery action,\nit will inevitably call the ARM-related function interface. I'll try to optimize it,\nand try to reduce the arch specific code introduction.\n\n> \n> \n> Delaying the handling until we re-enter user-space means faults that may affect\n> the kernel aren't handled until much later. Just because the fault was\n> synchronous and user-space was running doesn't mean only user space is affected.\n> Some examples I've collected so far: the zero-page may be corrupt, this is\n> mapped into every process and used by the kernel. Similarly corruption in the\n> vdso affects all user-space. The fault may affect the page tables, this affects\n> all users of the mm_struct.\n\nIn fact, compared to the current processing, we did not delay for a long time.\n\n1) For kernel-space errors, TIF flag is ignored, die() is called directly.\n2) For user-space errors, the current processing is to send SIGBUS directly.\n In this patchset, the memory_failure() is inserted before do_signal().\n\nAnd for error itself, memory_failure() could detect the page type and do appropriate action.\n\n> \n> (I'm sure we agree that an synchronous-external-abort interrupting the kernel is\n> fatal for the kernel, but the other way round isn't always true).\n> \n> Setting a TIF flag to handle the error before re-entering user-space is a\n> problem as the scheduler may choose to pre-empt this task and run all the other\n> tasks before this eventually gets handled.\n> \n> \n> Assuming this is just a problem with memory_failure_queue(), two alternatives I\n> can suggest are making memory_failure_queue() nmi-safe, or abstracting\n> NOTIFY_NMI's estatus pool/cache to use for the arm64 NMI-like notifications too.\n> \n> If there is more to this, can you explain the problem you're trying to solve?\n> (I suspect there may be an issue with multiple-signals being merged, or exactly\n> when memory_failure_queue()'s work gets run.) Can you outline the sequence of\n> events?\n> \n> \n> You're picking a physical address out of 'ARM Processor Error Information\n> Structure', these correspond with Cache, TLB, Bus or (the mysterious) 'micro\n> architectural error'. I don't see anything checking the error type.\n> Given the physical address, are you adding error-handling for cache-errors with\n> this series?\n\nYes, we only care about cache-errors. So we could just pick physical address\nfor cache errors.\n\n> \n> \n> Thanks,\n> \n> James\n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"BZGvwlMe\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrVJ40p8Zz9s4s\n\tfor ;\n\tTue, 12 Sep 2017 00:12:52 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1drPSC-0006EC-Hj; Mon, 11 Sep 2017 14:12:48 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1drPS3-0006At-H5 for linux-arm-kernel@lists.infradead.org;\n\tMon, 11 Sep 2017 14:12:46 +0000","from 172.30.72.58 (EHLO DGGEMS407-HUB.china.huawei.com)\n\t([172.30.72.58])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHC12793; Mon, 11 Sep 2017 22:11:38 +0800 (CST)","from [127.0.0.1] (10.177.19.210) by DGGEMS407-HUB.china.huawei.com\n\t(10.3.19.207) with Microsoft SMTP Server id 14.3.301.0;\n\tMon, 11 Sep 2017 22:11:30 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=wIYKaNXo4XlBweHWa6AsVkfrF2p9ZuDrS9lzljLUHoI=;\n\tb=BZGvwlMepVtVzq\n\tekXtnCQ3zwvIgqAp/zAWjv7H5W919ZtSuRrOlU0rNSmEQJUDzvJHPfIiJ8TaQWwcFfJu7xXCe9brK\n\trTaUQNMocJ3x0iZGLXoarHWK1lBegRBKZjCKya+8Rku0VeT2fypCPVjSfkcSt0XEi87ERD47dW/9k\n\tX4J0wdu2RpvDjEycXletY+rXFDGXJqtPEcLvzUsZsVhlhD2fECOuzgUdtvpVmxvMCy8ELywgZAc5u\n\tB7raDskTJqT7pl38LkuGvg8ussDZ6dnch7vqTCTMgOTP2togilQxWOJMV9th9F5GLKNAMV9XbEP4I\n\tpbjfJ1HFn7KaLs2+Ti9g==;","Subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","To":"James Morse ","References":"<1504770316-4327-1-git-send-email-xiexiuqi@huawei.com>\n\t<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>\n\t<59B2DE26.4060002@arm.com>","From":"Xie XiuQi ","Message-ID":"<52d2868c-79cd-8ff8-8e1d-6078d02d5a0c@huawei.com>","Date":"Mon, 11 Sep 2017 22:11:26 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<59B2DE26.4060002@arm.com>","X-Originating-IP":"[10.177.19.210]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020204.59B6999B.010C, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"e3d7d82c6511f5bbcd79035cd3bc61a9","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170911_071240_226728_BB4E8A53 ","X-CRM114-Status":"GOOD ( 36.14 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, wangkefeng.wang@huawei.com, cj.chengjian@huawei.com,\n\tjulien.thierry@arm.com, catalin.marinas@arm.com,\n\tstephen.boyd@linaro.org, \n\twill.deacon@arm.com, lijinyue@huawei.com, huawei.libin@huawei.com,\n\tguohanjun@huawei.com, wangxiongfeng2@huawei.com,\n\ttakahiro.akashi@linaro.org, \n\tzjzhang@codeaurora.org, gengdongjiu@huawei.com,\n\tlinux-acpi@vger.kernel.org, \n\tmingo@redhat.com, bp@suse.de, Dave.Martin@arm.com,\n\ttbaicar@codeaurora.org, \n\tzhengqiang10@huawei.com, linux-arm-kernel@lists.infradead.org,\n\tard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org,\n\tshiju.jose@huawei.com","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1769358,"web_url":"http://patchwork.ozlabs.org/comment/1769358/","msgid":"<59BC1CEE.8010708@arm.com>","list_archive_url":null,"date":"2017-09-15T18:33:18","subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","submitter":{"id":66575,"url":"http://patchwork.ozlabs.org/api/people/66575/","name":"James Morse","email":"james.morse@arm.com"},"content":"Hi Xie XiuQi,\n\nOn 11/09/17 15:11, Xie XiuQi wrote:\n> I first describe the approach of this patchset:\n> \n> A memory access error on the execution path usually triggers SEA.\n> According to the existing process, errors occurred in the kernel,\n> leading to direct panic, if it occurred the user-space, we should\n> just kill process.\n> \n> But there is a class of error, in fact, is not necessary to kill\n> process, you can recover and continue to run the process. Such as\n> the instruction data corrupted, where the memory page might be\n> read-only, which is has not been modified, the disk might have the\n> correct data, so you can directly drop the page, ant reload it when\n> necessary.\n> \n> So this patchset is just try to solve such problem: if the error is\n> consumed in user-space and the error occurs on a clean page, you can\n> directly drop the memory page without killing process.\n> \n> This is implemented in memory_failure, which is generic process.\n\n> The error reported by SEA should be handled before re-enter the process,\n> or we must kill the process to prevent error propagation.\n> \n> memory_failure_queue() is asynchronous, in which, error info was saved\n> at ghes_proc, but handled in kworker. During this period there is a context\n> switching, so we can not determine which process would be switch to. So\n> memory_failure_queue is not suitable for handling the problem.\n\nThanks for this summary. I see the problem you're trying to solve is when\nmemory_failure() runs, in your scenario its not guaranteed to run before we\nreturn to user space.\n\nWhat is the user-visible symptom of this? SIGBUS, code=0 instead of SIGBUS,\ncode=...MCEERR_A?\n\n..in which case I'm looking at this as a race with the memory_failure() bottom\nhalf via schedule_work().\n\nHow does x86 avoid this same problem?\n\n\n> And memory_failure is not nmi-safe, so it can not be called directly in the\n> SEA context. So we just handle this error at SEA exit path, and before context\n> switching.\n\n(I need to look more into which locks memory_failure() is taking)\n\n\n> In FFH mode, physical address can only be obtained by parsing the GHES table.\n> But we only care about SEA, so the error handling is tied to the type of notification.\n\nI care about all the notification methods. Once the notification has been passed\nto APEI I want them to behave the same so that we don't have subtle bugs between\nthe 11 different ways we could get a notification. This code is rarely tested\nenough as it is.\n\n>From the arch code I just want to call out to APEI asking 'is this yours?'. If\nso I expect APEI to have done all the work, if not we take the v8.0 behaviour.\n\n\nHere you need APEI and the arch code to spot 'SEA' and treat it differently,\ninvoking some arm64-specific behaviour for APEI, and some\nnot-really-arch-specific code under /arch/arm64. There is nothing arm64 specific\nabout your arm_process_error(), how come the core APEI code doesn't need to do this?\n\n\nI think this is caused by the way memory_failure() schedules its work, and that\nis where I'd like to try and fix this, so that its the same for all notification\nmethods and all (cough: both) architectures.\n\n\n> The TIF flag is checked on a generic path, but it will only be set when SEA occurs.\n> And if we use unlikely optimization, it should have little impact on performance.\n\nYes, the arch code checks _TIF_WORK_MASK in one go so there is no performance\nproblem for code that hasn't taken the RAS-Error. (and once we've taken a RAS\nerror performance is out the window!)\n\n\n> And the TIF flag approach was used on x86 platform for years, until commit d4812e169d\n\n... so x86 doesn't do this ...\n\n> (x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks)[0]. On currently arm64\n> platform, there is no IST interrupt[1] function, so we could not call memory_failure\n> directly in SEA context. So the way to use TIF notification, is also a good choice,\n> after all, the same way on x86 platform is verified.\n\nThanks, looks like I need to read more of the history of x86's kernel-first\nhandling...\n\n\nThanks,\n\nJames","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"oKUAqW+l\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xv3x05Prdz9s7h\n\tfor ;\n\tSat, 16 Sep 2017 04:35:16 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsvSL-0000qO-In; Fri, 15 Sep 2017 18:35:13 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsvSH-00082y-GY for linux-arm-kernel@lists.infradead.org;\n\tFri, 15 Sep 2017 18:35:11 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 67C5315A2;\n\tFri, 15 Sep 2017 11:34:48 -0700 (PDT)","from [10.1.207.55] (melchizedek.cambridge.arm.com [10.1.207.55])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t8CF353F3E1; Fri, 15 Sep 2017 11:34:44 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Subject:To:\n\tMIME-Version:From:Date:Message-ID:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=KfsGoDM37GcPXOgds6xP0ZQfdpoOkTvfxorfv67e7KU=;\n\tb=oKUAqW+lDdSw67\n\tLN/WtHrZNxPzWCPuIK2MTrYziZdjqNxyGZyTV/Gcjp2gOcnFu/pyOTm3XuLXHafOB+bwBg6PeG+my\n\tW6pWCX4DTqmAHlOQKR9CC7iU1xZiLTCbkEkfKMv0Iw9yHdExZt2wRA7GGDnR5FptBoRigWIh+FeXP\n\thIuJK5Rrhyb6QNVt+YMVJvVOsRUjHeJh/RyP7TPheETxdjTmt96ys5X97KUpO4T2mGsvF3VA7DQTf\n\tZvcFwKfscfxHQfTF9oQ+GWXnXHzMHRHihiidR0aFbCsligyPVZVzF9uL+Dn7MTZ5FDAaBWMI2dfoz\n\tThsE54kVdbh4eCn2I54A==;","Message-ID":"<59BC1CEE.8010708@arm.com>","Date":"Fri, 15 Sep 2017 19:33:18 +0100","From":"James Morse ","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:31.0) Gecko/20100101 Icedove/31.6.0","MIME-Version":"1.0","To":"Xie XiuQi ","Subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","References":"<1504770316-4327-1-git-send-email-xiexiuqi@huawei.com>\n\t<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>\n\t<59B2DE26.4060002@arm.com>\n\t<52d2868c-79cd-8ff8-8e1d-6078d02d5a0c@huawei.com>","In-Reply-To":"<52d2868c-79cd-8ff8-8e1d-6078d02d5a0c@huawei.com>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170915_113509_575868_669FB62F ","X-CRM114-Status":"GOOD ( 29.54 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, wangkefeng.wang@huawei.com, cj.chengjian@huawei.com,\n\tjulien.thierry@arm.com, catalin.marinas@arm.com,\n\tstephen.boyd@linaro.org, \n\twill.deacon@arm.com, lijinyue@huawei.com, huawei.libin@huawei.com,\n\tguohanjun@huawei.com, wangxiongfeng2@huawei.com,\n\ttakahiro.akashi@linaro.org, \n\tzjzhang@codeaurora.org, gengdongjiu@huawei.com,\n\tlinux-acpi@vger.kernel.org, \n\tmingo@redhat.com, bp@suse.de, Dave.Martin@arm.com,\n\ttbaicar@codeaurora.org, \n\tzhengqiang10@huawei.com, linux-arm-kernel@lists.infradead.org,\n\tard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org,\n\tshiju.jose@huawei.com","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1771851,"web_url":"http://patchwork.ozlabs.org/comment/1771851/","msgid":"<2b540452-2fa6-322a-e7ee-63a0653b8548@huawei.com>","list_archive_url":null,"date":"2017-09-20T13:34:57","subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","submitter":{"id":24815,"url":"http://patchwork.ozlabs.org/api/people/24815/","name":"Xie XiuQi","email":"xiexiuqi@huawei.com"},"content":"Hi James,\n\nI try to explain some of following questions.\n\nOn 2017/9/16 2:33, James Morse wrote:\n> Hi Xie XiuQi,\n> \n> On 11/09/17 15:11, Xie XiuQi wrote:\n>> I first describe the approach of this patchset:\n>>\n>> A memory access error on the execution path usually triggers SEA.\n>> According to the existing process, errors occurred in the kernel,\n>> leading to direct panic, if it occurred the user-space, we should\n>> just kill process.\n>>\n>> But there is a class of error, in fact, is not necessary to kill\n>> process, you can recover and continue to run the process. Such as\n>> the instruction data corrupted, where the memory page might be\n>> read-only, which is has not been modified, the disk might have the\n>> correct data, so you can directly drop the page, ant reload it when\n>> necessary.\n>>\n>> So this patchset is just try to solve such problem: if the error is\n>> consumed in user-space and the error occurs on a clean page, you can\n>> directly drop the memory page without killing process.\n>>\n>> This is implemented in memory_failure, which is generic process.\n> \n>> The error reported by SEA should be handled before re-enter the process,\n>> or we must kill the process to prevent error propagation.\n>>\n>> memory_failure_queue() is asynchronous, in which, error info was saved\n>> at ghes_proc, but handled in kworker. During this period there is a context\n>> switching, so we can not determine which process would be switch to. So\n>> memory_failure_queue is not suitable for handling the problem.\n> \n> Thanks for this summary. I see the problem you're trying to solve is when\n> memory_failure() runs, in your scenario its not guaranteed to run before we\n> return to user space.\n> \n> What is the user-visible symptom of this? SIGBUS, code=0 instead of SIGBUS,\n> code=...MCEERR_A?\n\nIf the corrupted page is clean, just dropped it and return to user-space without\nside effects. And if corrupted page is dirty, memory_failure() will send SIGBUS\nwith code=BUS_MCEERR_AR.\n\n> \n> ..in which case I'm looking at this as a race with the memory_failure() bottom\n> half via schedule_work().\n\nDo you mean there is a race between memory_failure() from do_notify_resume() and\nfrom schedule_work()? Indeed there a race here, thank you for pointing out that.\n\nActually, memory_failure_queue() is not needed in SEA case if we process it in\nsynchronous.\n\nI'll try to solve this issue later.\n\n> \n> How does x86 avoid this same problem?\n> \n> \n>> And memory_failure is not nmi-safe, so it can not be called directly in the\n>> SEA context. So we just handle this error at SEA exit path, and before context\n>> switching.\n> \n> (I need to look more into which locks memory_failure() is taking)\n> \n> \n>> In FFH mode, physical address can only be obtained by parsing the GHES table.\n>> But we only care about SEA, so the error handling is tied to the type of notification.\n> \n> I care about all the notification methods. Once the notification has been passed\n> to APEI I want them to behave the same so that we don't have subtle bugs between\n> the 11 different ways we could get a notification. This code is rarely tested\n> enough as it is.\n> \n>>From the arch code I just want to call out to APEI asking 'is this yours?'. If\n> so I expect APEI to have done all the work, if not we take the v8.0 behaviour.\n> \n> \n> Here you need APEI and the arch code to spot 'SEA' and treat it differently,\n> invoking some arm64-specific behaviour for APEI, and some\n> not-really-arch-specific code under /arch/arm64. There is nothing arm64 specific\n> about your arm_process_error(), how come the core APEI code doesn't need to do this?\n> \n> \n> I think this is caused by the way memory_failure() schedules its work, and that\n> is where I'd like to try and fix this, so that its the same for all notification\n> methods and all (cough: both) architectures.\n\nI try to see if there is a better way.\n\n> \n> \n>> The TIF flag is checked on a generic path, but it will only be set when SEA occurs.\n>> And if we use unlikely optimization, it should have little impact on performance.\n> \n> Yes, the arch code checks _TIF_WORK_MASK in one go so there is no performance\n> problem for code that hasn't taken the RAS-Error. (and once we've taken a RAS\n> error performance is out the window!)\n> \n>> And the TIF flag approach was used on x86 platform for years, until commit d4812e169d\n> \n> ... so x86 doesn't do this ...\n> \n>> (x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks)[0]. On currently arm64\n>> platform, there is no IST interrupt[1] function, so we could not call memory_failure\n>> directly in SEA context. So the way to use TIF notification, is also a good choice,\n>> after all, the same way on x86 platform is verified.\n> \n> Thanks, looks like I need to read more of the history of x86's kernel-first\n> handling...\n> \n> \n> Thanks,\n> \n> James\n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"fZKvGVSZ\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xy1471SWsz9s7f\n\tfor ;\n\tWed, 20 Sep 2017 23:36:39 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dufAz-0007TB-3L; Wed, 20 Sep 2017 13:36:29 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dufAr-0007N0-1W for linux-arm-kernel@lists.infradead.org;\n\tWed, 20 Sep 2017 13:36:27 +0000","from 172.30.72.60 (EHLO DGGEMS403-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHP92813; Wed, 20 Sep 2017 21:35:25 +0800 (CST)","from [127.0.0.1] (10.177.19.210) by DGGEMS403-HUB.china.huawei.com\n\t(10.3.19.203) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 20 Sep 2017 21:35:13 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=tapeGAaI1mJkPLgHNrWlF5yzBM/bBbk7B89Tfd6csRo=;\n\tb=fZKvGVSZjvSJ6s\n\taCRKWECPIyToVt+ccxmTleVt4lDedZpFZnLLxLBM3d2c1EKjafpY0JkYVY+nvJmyLnfC9Lxx+p61E\n\tKcVgQKBBdzOaKeOH/rrvCZT5sxlHm03ayhnOhdbgxB0FMJMA7ZVDyQFfujCChfpUhgQm1xsE5K7eV\n\tfcWCVtJSJhcTmOJZ3cIMBUZ7j5exFdVI41+GiTHwTppG7Im+zI1dKlN+pq78uDSmR5SkSU9DwA3aP\n\tRwOwGFCbZfXmMfO/qKgZ0o+m9YJ3TfrdejwWpab/Os64KavbkTIZp5unOvPClJMl5p6L0gqpJLRFO\n\tgadOqeC9r9xMk4LFwGZg==;","Subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","To":"James Morse ","References":"<1504770316-4327-1-git-send-email-xiexiuqi@huawei.com>\n\t<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>\n\t<59B2DE26.4060002@arm.com>\n\t<52d2868c-79cd-8ff8-8e1d-6078d02d5a0c@huawei.com>\n\t<59BC1CEE.8010708@arm.com>","From":"Xie XiuQi ","Message-ID":"<2b540452-2fa6-322a-e7ee-63a0653b8548@huawei.com>","Date":"Wed, 20 Sep 2017 21:34:57 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<59BC1CEE.8010708@arm.com>","X-Originating-IP":"[10.177.19.210]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090204.59C26E9E.0335, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"82dc24051ab39f7d7909c3b46a801262","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170920_063621_665093_7B4350C2 ","X-CRM114-Status":"GOOD ( 30.80 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, wangkefeng.wang@huawei.com, cj.chengjian@huawei.com,\n\tjulien.thierry@arm.com, catalin.marinas@arm.com,\n\tstephen.boyd@linaro.org, \n\twill.deacon@arm.com, lijinyue@huawei.com, huawei.libin@huawei.com,\n\tguohanjun@huawei.com, wangxiongfeng2@huawei.com,\n\ttakahiro.akashi@linaro.org, \n\tzjzhang@codeaurora.org, gengdongjiu@huawei.com,\n\tlinux-acpi@vger.kernel.org, \n\tmingo@redhat.com, bp@suse.de, Dave.Martin@arm.com,\n\ttbaicar@codeaurora.org, \n\tzhengqiang10@huawei.com, linux-arm-kernel@lists.infradead.org,\n\tard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org,\n\tshiju.jose@huawei.com","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1776325,"web_url":"http://patchwork.ozlabs.org/comment/1776325/","msgid":"<9bff629e-020a-d6f9-b688-36f8347ac5e5@huawei.com>","list_archive_url":null,"date":"2017-09-27T12:42:32","subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","submitter":{"id":24815,"url":"http://patchwork.ozlabs.org/api/people/24815/","name":"Xie XiuQi","email":"xiexiuqi@huawei.com"},"content":"Hi James,\n\nI'll send v4 to fix some small issue, for same one who interested\nwith this feature could test it. For the question you mentioned,\nI will study in depth.\n\nAny comments is welcome.\n\nOn 2017/9/16 2:33, James Morse wrote:\n> Hi Xie XiuQi,\n> \n> On 11/09/17 15:11, Xie XiuQi wrote:\n>> I first describe the approach of this patchset:\n>>\n>> A memory access error on the execution path usually triggers SEA.\n>> According to the existing process, errors occurred in the kernel,\n>> leading to direct panic, if it occurred the user-space, we should\n>> just kill process.\n>>\n>> But there is a class of error, in fact, is not necessary to kill\n>> process, you can recover and continue to run the process. Such as\n>> the instruction data corrupted, where the memory page might be\n>> read-only, which is has not been modified, the disk might have the\n>> correct data, so you can directly drop the page, ant reload it when\n>> necessary.\n>>\n>> So this patchset is just try to solve such problem: if the error is\n>> consumed in user-space and the error occurs on a clean page, you can\n>> directly drop the memory page without killing process.\n>>\n>> This is implemented in memory_failure, which is generic process.\n> \n>> The error reported by SEA should be handled before re-enter the process,\n>> or we must kill the process to prevent error propagation.\n>>\n>> memory_failure_queue() is asynchronous, in which, error info was saved\n>> at ghes_proc, but handled in kworker. During this period there is a context\n>> switching, so we can not determine which process would be switch to. So\n>> memory_failure_queue is not suitable for handling the problem.\n> \n> Thanks for this summary. I see the problem you're trying to solve is when\n> memory_failure() runs, in your scenario its not guaranteed to run before we\n> return to user space.\n> \n> What is the user-visible symptom of this? SIGBUS, code=0 instead of SIGBUS,\n> code=...MCEERR_A?\n> \n> ..in which case I'm looking at this as a race with the memory_failure() bottom\n> half via schedule_work().\n> \n> How does x86 avoid this same problem?\n> \n> \n>> And memory_failure is not nmi-safe, so it can not be called directly in the\n>> SEA context. So we just handle this error at SEA exit path, and before context\n>> switching.\n> \n> (I need to look more into which locks memory_failure() is taking)\n> \n> \n>> In FFH mode, physical address can only be obtained by parsing the GHES table.\n>> But we only care about SEA, so the error handling is tied to the type of notification.\n> \n> I care about all the notification methods. Once the notification has been passed\n> to APEI I want them to behave the same so that we don't have subtle bugs between\n> the 11 different ways we could get a notification. This code is rarely tested\n> enough as it is.\n> \n>>From the arch code I just want to call out to APEI asking 'is this yours?'. If\n> so I expect APEI to have done all the work, if not we take the v8.0 behaviour.\n> \n> \n> Here you need APEI and the arch code to spot 'SEA' and treat it differently,\n> invoking some arm64-specific behaviour for APEI, and some\n> not-really-arch-specific code under /arch/arm64. There is nothing arm64 specific\n> about your arm_process_error(), how come the core APEI code doesn't need to do this?\n> \n> \n> I think this is caused by the way memory_failure() schedules its work, and that\n> is where I'd like to try and fix this, so that its the same for all notification\n> methods and all (cough: both) architectures.\n> \n> \n>> The TIF flag is checked on a generic path, but it will only be set when SEA occurs.\n>> And if we use unlikely optimization, it should have little impact on performance.\n> \n> Yes, the arch code checks _TIF_WORK_MASK in one go so there is no performance\n> problem for code that hasn't taken the RAS-Error. (and once we've taken a RAS\n> error performance is out the window!)\n> \n> \n>> And the TIF flag approach was used on x86 platform for years, until commit d4812e169d\n> \n> ... so x86 doesn't do this ...\n> \n>> (x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks)[0]. On currently arm64\n>> platform, there is no IST interrupt[1] function, so we could not call memory_failure\n>> directly in SEA context. So the way to use TIF notification, is also a good choice,\n>> after all, the same way on x86 platform is verified.\n> \n> Thanks, looks like I need to read more of the history of x86's kernel-first\n> handling...\n> \n> \n> Thanks,\n> \n> James\n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"Jk5C2TRU\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"ie2GstAq\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y2J1D6JB0z9tXQ\n\tfor ;\n\tWed, 27 Sep 2017 23:04:00 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxC0I-00083P-Sn; Wed, 27 Sep 2017 13:03:54 +0000","from casper.infradead.org ([2001:8b0:10b:1236::1])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxC0G-0007nd-W7 for linux-arm-kernel@bombadil.infradead.org;\n\tWed, 27 Sep 2017 13:03:53 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby casper.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dxBmK-0002NY-Ov for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 12:49:31 +0000","from 172.30.72.60 (EHLO DGGEMS401-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DID14864; Wed, 27 Sep 2017 20:42:49 +0800 (CST)","from [127.0.0.1] (10.177.19.210) by DGGEMS401-HUB.china.huawei.com\n\t(10.3.19.201) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 27 Sep 2017 20:42:37 +0800"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=Ku/TQMg8T4BhgmsYhxJp2wUDm2EMitxeAKBGcYuAoIk=;\n\tb=Jk5C2TRUXwoS+v\n\tCY5EHECcBz78pJCNAv8swNEMSfNLR1enD+R7C2P5ULy7XafGmusFRTnKrpgUXWfKxd1hh0PsoOnOM\n\t8qPKo5iUNQMghRbxErqDvUwqFtMlgI2VJ46xkl+ULLFknXL+ohPAFY2KPDD6ajidbgUNKVxQbAFOn\n\tehyUZPju6C6umCWj2i0A/VXh4pBLCJsyx/s0Br3U4EIew+y+r8sjZzARJlqXNWdKKTc+zlSTMmb17\n\teugx1RsNQjkd3ZuQABmGeJms0+azQ/efSREzD3SzG2ISAJr0gE3a3l9oLl9mDrj4n0fzYbPoFqlFK\n\t2ZrQtf6jBpaJzXu1MX6w==;","v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209;\n\th=Content-Transfer-Encoding:Content-Type:\n\tIn-Reply-To:MIME-Version:Date:Message-ID:From:CC:References:To:Subject:Sender\n\t:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:\n\tResent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:\n\tList-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;\n\tbh=yXLeV+v1PrRQqpY9P4RHNoQDXnBYH4Uc3VqZYCZG6AQ=;\n\tb=ie2GstAqPQT/axjnhtaXLjdMXM\n\tBw201+LDWP35LPRPufTuodnamN3U2vs3NZ5sNAPePBQkzkJCY+qZG6lOLBTMdZuC14KyIHiBJ0AtQ\n\trt3ft9ia84sjLQZ4CNzRXN/eVf8tUwSgw9ebP0MxwMfWZVhzzJ/EUjm/T/gfUyqDmAMr2Jboz58TU\n\tJkSN8y8uLwFcVlGOH9PLemwc1uyC/w4ipbBe31so07NA9KqDnbjRbEPO2T2ysgdzoxNeHSkgjcSw9\n\tQXr/Rh2Y3AoxF3D5TtdEFAFrXsONyn6V6zGlQv+hD/8yHmxhR/3fimTiaFqjPx7GsHtjuLNUA4b5G\n\trkRyEO0Q==;"],"Subject":"Re: [PATCH v3 1/3] arm64/ras: support sea error recovery","To":"James Morse ","References":"<1504770316-4327-1-git-send-email-xiexiuqi@huawei.com>\n\t<1504770316-4327-2-git-send-email-xiexiuqi@huawei.com>\n\t<59B2DE26.4060002@arm.com>\n\t<52d2868c-79cd-8ff8-8e1d-6078d02d5a0c@huawei.com>\n\t<59BC1CEE.8010708@arm.com>","From":"Xie XiuQi ","Message-ID":"<9bff629e-020a-d6f9-b688-36f8347ac5e5@huawei.com>","Date":"Wed, 27 Sep 2017 20:42:32 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<59BC1CEE.8010708@arm.com>","X-Originating-IP":"[10.177.19.210]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020204.59CB9CCA.00B7, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"e3d7d82c6511f5bbcd79035cd3bc61a9","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170927_134929_871471_FB814E95 ","X-CRM114-Status":"GOOD ( 46.82 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on casper.infradead.org summary:\n\tContent analysis details: (-1.9 points, 5.0 required)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"mark.rutland@arm.com, wangkefeng.wang@huawei.com, cj.chengjian@huawei.com,\n\tjulien.thierry@arm.com, catalin.marinas@arm.com,\n\tstephen.boyd@linaro.org, \n\twill.deacon@arm.com, lijinyue@huawei.com, huawei.libin@huawei.com,\n\tguohanjun@huawei.com, wangxiongfeng2@huawei.com,\n\ttakahiro.akashi@linaro.org, \n\tzjzhang@codeaurora.org, gengdongjiu@huawei.com,\n\tlinux-acpi@vger.kernel.org, \n\tmingo@redhat.com, bp@suse.de, Dave.Martin@arm.com,\n\ttbaicar@codeaurora.org, \n\tzhengqiang10@huawei.com, linux-arm-kernel@lists.infradead.org,\n\tard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org,\n\tshiju.jose@huawei.com","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]