From mboxrd@z Thu Jan 1 00:00:00 1970 From: wangxiongfeng2@huawei.com (Xiongfeng Wang) Date: Tue, 9 May 2017 10:16:32 +0800 Subject: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt In-Reply-To: <5910AA92.2010106@arm.com> 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> <5910AA92.2010106@arm.com> Message-ID: <4cfa4f66-e9a2-fd52-fb64-b2510bcdf1d8@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi James, On 2017/5/9 1:27, James Morse wrote: > 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. > Yes, it makes sense, so we should add a return value for the do_sei handler. Thanks, Wang Xiongfeng