From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755277AbdEHR2Y (ORCPT ); Mon, 8 May 2017 13:28:24 -0400 Received: from foss.arm.com ([217.140.101.70]:45738 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754244AbdEHR2X (ORCPT ); Mon, 8 May 2017 13:28:23 -0400 Message-ID: <5910AA92.2010106@arm.com> Date: Mon, 08 May 2017 18:27:46 +0100 From: James Morse User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Xiongfeng Wang CC: Mark Rutland , Xie XiuQi , christoffer.dall@linaro.org, marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, fu.wei@linaro.org, rostedt@goodmis.org, hanjun.guo@linaro.org, shiju.jose@huawei.com, wuquanming@huawei.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, gengdongjiu@huawei.com, linux-acpi@vger.kernel.org, zhengqiang10@huawei.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt References: <1490869877-118713-1-git-send-email-xiexiuqi@huawei.com> <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com> <20170413105131.GD24027@leverpostej> <58F5EFC6.5070601@arm.com> <58F876EB.2020805@arm.com> <2bb41d98-553f-1361-e497-4095ddd501d0@huawei.com> <58FE328E.7030106@arm.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Xiongfeng Wang, On 28/04/17 03:55, Xiongfeng Wang wrote: >>> >> It is ok to just ignore the process following the ESB instruction in el0_sync, because the process will be sent SIGBUS signal. >> > >> > I don't understand. How will Linux know the process caused an error if we >> > neither take an SError nor read DISR_EL1 after an ESB? > I think there may be some misunderstanding here. The ESB instruction is placed in kernel_entry > of el0_sync and el0_irq. For the el0_sync, such as an syscall from userspace, after ESB is executed, > we check whether DISR.A is set. If it is not set, we go on to process the syscall. If it is set, we > jump to sError vector and then just eret. Ah, this looks like an early optimisation! We can't assume that the SError will result in the processing being killed, the AET bits of the SError ISS Encoding (page D7-2284 of ARM-ARM DDI0487B.a), has a 'corrected' error encoding. For these I would expect the SError-vector C code to do nothing and return to where it came from. In this case the syscall should still be run. Thanks, James