From: Florian Fainelli <f.fainelli@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>, Doug Berger <opendmb@gmail.com>
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
Subject: Re: [PATCH 3/9] arm64: mm: install SError abort handler
Date: Fri, 24 Mar 2017 10:53:48 -0700 [thread overview]
Message-ID: <710c4142-ae20-9715-3e51-910a2073a64e@gmail.com> (raw)
In-Reply-To: <20170324173515.GB10746@leverpostej>
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
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>, Doug Berger <opendmb@gmail.com>
Cc: wangkefeng.wang@huawei.com, catalin.marinas@arm.com,
linus.walleij@linaro.org, will.deacon@arm.com, mingo@kernel.org,
panand@redhat.com, f.fainelli@gmail.com, jonathanh@nvidia.com,
bgolaszewski@baylibre.com, bcm-kernel-feedback-list@broadcom.com,
shijie.huang@arm.com, treding@nvidia.com,
devicetree@vger.kernel.org, vladimir.murzin@arm.com,
cmetcalf@mellanox.com, suzuki.poulose@arm.com,
andre.przywara@arm.com, robh+dt@kernel.org,
gregory.0xf0@gmail.com, sandeepa.s.prabhu@gmail.com,
horms+renesas@verge.net.au, linux-arm-kernel@lists.infradead.org,
mirza.krak@gmail.com, linux-kernel@vger.kernel.org,
james.morse@arm.com, olof@lixom.net, computersforpeace@gmail.com
Subject: Re: [PATCH 3/9] arm64: mm: install SError abort handler
Date: Fri, 24 Mar 2017 10:53:48 -0700 [thread overview]
Message-ID: <710c4142-ae20-9715-3e51-910a2073a64e@gmail.com> (raw)
In-Reply-To: <20170324173515.GB10746@leverpostej>
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
WARNING: multiple messages have this Message-ID (diff)
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/9] arm64: mm: install SError abort handler
Date: Fri, 24 Mar 2017 10:53:48 -0700 [thread overview]
Message-ID: <710c4142-ae20-9715-3e51-910a2073a64e@gmail.com> (raw)
In-Reply-To: <20170324173515.GB10746@leverpostej>
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
next prev parent reply other threads:[~2017-03-24 17:54 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 14:46 [PATCH 0/9] bus: brcmstb_gisb: add support for GISBv7 arbiter Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` [PATCH 1/9] arm64: mm: Allow installation of memory abort handlers Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` [PATCH 2/9] arm64: mm: mark fault_info __ro_after_init Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` [PATCH 3/9] arm64: mm: install SError abort handler Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 15:16 ` Mark Rutland
2017-03-24 15:16 ` Mark Rutland
2017-03-24 15:16 ` Mark Rutland
2017-03-24 16:48 ` Doug Berger
2017-03-24 16:48 ` Doug Berger
2017-03-24 16:48 ` Doug Berger
2017-03-24 17:35 ` Mark Rutland
2017-03-24 17:35 ` Mark Rutland
2017-03-24 17:35 ` Mark Rutland
2017-03-24 17:53 ` Florian Fainelli [this message]
2017-03-24 17:53 ` Florian Fainelli
2017-03-24 17:53 ` Florian Fainelli
2017-03-24 18:31 ` Mark Rutland
2017-03-24 18:31 ` Mark Rutland
2017-03-24 18:31 ` Mark Rutland
2017-03-24 19:02 ` Florian Fainelli
2017-03-24 19:02 ` Florian Fainelli
2017-03-24 19:02 ` Florian Fainelli
2017-03-25 10:06 ` Marc Zyngier
2017-03-25 10:06 ` Marc Zyngier
2017-03-27 20:19 ` Florian Fainelli
2017-03-27 20:19 ` Florian Fainelli
2017-03-27 20:19 ` Florian Fainelli
2017-03-24 14:46 ` [PATCH 4/9] bus: brcmstb_gisb: Use register offsets with writes too Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-25 5:21 ` Gregory Fong
2017-03-25 5:21 ` Gregory Fong
2017-03-25 5:21 ` Gregory Fong
2017-03-24 14:46 ` [PATCH 5/9] bus: brcmstb_gisb: Correct hooking of ARM aborts Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` [PATCH 6/9] bus: brcmstb_gisb: correct support for 64-bit address output Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-25 5:36 ` Gregory Fong
2017-03-25 5:36 ` Gregory Fong
2017-03-25 5:36 ` Gregory Fong
2017-03-24 14:46 ` [PATCH 7/9] bus: brcmstb_gisb: Add ARM64 support Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` [PATCH 8/9] bus: brcmstb_gisb: add ARM64 SError support Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 14:46 ` [PATCH 9/9] bus: brcmstb_gisb: update to support new revision Doug Berger
2017-03-24 14:46 ` Doug Berger
2017-03-24 15:03 ` [PATCH 0/9] bus: brcmstb_gisb: add support for GISBv7 arbiter Mark Rutland
2017-03-24 15:03 ` Mark Rutland
2017-03-24 16:02 ` Doug Berger
2017-03-24 16:02 ` Doug Berger
2017-03-24 16:02 ` Doug Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=710c4142-ae20-9715-3e51-910a2073a64e@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andre.przywara@arm.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bgolaszewski@baylibre.com \
--cc=catalin.marinas@arm.com \
--cc=cmetcalf@mellanox.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=gregory.0xf0@gmail.com \
--cc=horms+renesas@verge.net.au \
--cc=james.morse@arm.com \
--cc=jonathanh@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mirza.krak@gmail.com \
--cc=olof@lixom.net \
--cc=opendmb@gmail.com \
--cc=panand@redhat.com \
--cc=robh+dt@kernel.org \
--cc=sandeepa.s.prabhu@gmail.com \
--cc=shijie.huang@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=treding@nvidia.com \
--cc=vladimir.murzin@arm.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.