From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751394AbeAYRLS (ORCPT ); Thu, 25 Jan 2018 12:11:18 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:44996 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbeAYRLO (ORCPT ); Thu, 25 Jan 2018 12:11:14 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3648B6032C Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=tbaicar@codeaurora.org Subject: Re: [PATCH v4 0/4] arm64/ras: support sea error recovery To: Xie XiuQi , catalin.marinas@arm.com, will.deacon@arm.com, mingo@redhat.com, mark.rutland@arm.com, ard.biesheuvel@linaro.org, james.morse@arm.com, Dave.Martin@arm.com, takahiro.akashi@linaro.org, stephen.boyd@linaro.org, bp@suse.de, julien.thierry@arm.com, shiju.jose@huawei.com, zjzhang@codeaurora.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, wangxiongfeng2@huawei.com, zhengqiang10@huawei.com, gengdongjiu@huawei.com, huawei.libin@huawei.com, wangkefeng.wang@huawei.com, lijinyue@huawei.com, guohanjun@huawei.com, hanjun.guo@linaro.org, cj.chengjian@huawei.com References: <1506516620-20033-1-git-send-email-xiexiuqi@huawei.com> From: Tyler Baicar Message-ID: Date: Thu, 25 Jan 2018 12:11:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1506516620-20033-1-git-send-email-xiexiuqi@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Xie, On 9/27/2017 8:50 AM, Xie XiuQi wrote: > With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors > are consumed. According to the existing process, errors occurred in the > kernel, leading to direct panic, if it occurred the user-space, we should > just kill process. > > But there is a class of error, in fact, is not necessary to kill > process, you can recover and continue to run the process. Such as > the instruction data corrupted, where the memory page might be > read-only, which is has not been modified, the disk might have the > correct data, so you can directly drop the page, ant reload it when > necessary. > > So this patchset is just try to solve such problem: if the error is > consumed in user-space and the error occurs on a clean page, you can > directly drop the memory page without killing process. > > If the corrupted page is clean, just dropped it and return to user-space > without side effects. And if corrupted page is dirty, memory_failure() > will send SIGBUS with code=BUS_MCEERR_AR. While without this patchset, > do_sea() will just send SIGBUS, so the process was killed in the same place. > > Because memory_failure() may sleep, we can not call it directly in SEA > exception context. So we saved faulting physical address associated with > a process in the ghes handler and set __TIF_SEA_NOTIFY. When we return > from SEA exception context and get into do_notify_resume() before the > process running, we could check it and call memory_failure() to do > recovery. It's safe, because we are in process context. > > In some platform, when SEA triggerred, physical address could be reported > by memory section or by processor section, so we save address at this two > place. For this series - Tested-by: Tyler Baicar Note that this will probably need to be rebased on top of these patches: https://patchwork.codeaurora.org/patch/415877/ https://patchwork.codeaurora.org/patch/415879/ With that, the first patch should be able to be removed because the above patches already define the ARM error types: +#define CPER_ARM_CACHE_ERROR            0 +#define CPER_ARM_TLB_ERROR            1 +#define CPER_ARM_BUS_ERROR            2 +#define CPER_ARM_VENDOR_ERROR            3 Thanks, Tyler -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.