Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933334AbdCXRy2 (ORCPT ); Fri, 24 Mar 2017 13:54:28 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:35579 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932339AbdCXRyT (ORCPT ); Fri, 24 Mar 2017 13:54:19 -0400 Subject: Re: [PATCH 3/9] arm64: mm: install SError abort handler To: Mark Rutland , Doug Berger References: <20170324144632.5896-1-opendmb@gmail.com> <20170324144632.5896-4-opendmb@gmail.com> <20170324151654.GD29588@leverpostej> <58D54DE8.9020707@gmail.com> <20170324173515.GB10746@leverpostej> Cc: catalin.marinas@arm.com, robh+dt@kernel.org, will.deacon@arm.com, computersforpeace@gmail.com, gregory.0xf0@gmail.com, f.fainelli@gmail.com, bcm-kernel-feedback-list@broadcom.com, wangkefeng.wang@huawei.com, james.morse@arm.com, vladimir.murzin@arm.com, panand@redhat.com, andre.przywara@arm.com, cmetcalf@mellanox.com, mingo@kernel.org, sandeepa.s.prabhu@gmail.com, shijie.huang@arm.com, linus.walleij@linaro.org, treding@nvidia.com, jonathanh@nvidia.com, olof@lixom.net, mirza.krak@gmail.com, suzuki.poulose@arm.com, bgolaszewski@baylibre.com, horms+renesas@verge.net.au, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org From: Florian Fainelli Message-ID: <710c4142-ae20-9715-3e51-910a2073a64e@gmail.com> Date: Fri, 24 Mar 2017 10:53:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170324173515.GB10746@leverpostej> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1041 Lines: 21 On 03/24/2017 10:35 AM, Mark Rutland wrote: > On Fri, Mar 24, 2017 at 09:48:40AM -0700, Doug Berger wrote: >> On 03/24/2017 08:16 AM, Mark Rutland wrote: >>> On Fri, Mar 24, 2017 at 07:46:26AM -0700, Doug Berger wrote: > >> If you would consider an alternative implementation where we scrap >> the SError handler (i.e. maintain the ugliness in our downstream >> kernel) in favor of a more gentle user mode crash on SError that >> allows the kernel the opportunity to service the interrupt for >> diagnostic purposes I could try to repackage that. > > If this is just for diagnostic purposes, I believe you can register a > panic notifier, which can then read from the bus. The panic will occur, > but you'll have the opportunity to log some information to dmesg. And crash the kernel? That sounds awful, FWIW the ARM/Linux kernel is able to recover just fine from user-space accessing e.g: invalid physical addresses in the GISB register space, bringing the same level of functionality to ARM64/Linux sounds reasonable to me. -- Florian