linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hari.vyas@broadcom.com (Hari Vyas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: fix for bad_mode() handler to always result in panic
Date: Wed, 22 Aug 2018 12:01:47 +0530	[thread overview]
Message-ID: <CAM5rFu-dbtmc2buJAOQQg+vGSPvu4coxz7JXg-biiMBNAn4Mvg@mail.gmail.com> (raw)
In-Reply-To: <20180821173838.GB5168@brain-police>

On Tue, Aug 21, 2018 at 11:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Hari,
>
> Sorry, this has slipped through the cracks.
>
> On Tue, Aug 21, 2018 at 07:46:04PM +0530, Hari Vyas wrote:
>> On Fri, Aug 10, 2018 at 10:16 PM, Hari Vyas <hari.vyas@broadcom.com> wrote:
>> > As far as I know, bad mode was earlier(linux 3.14 onwards) also not
>> > resulting in panic always.
>> > Trap-exception framework is recently changed some time back but this
>> > concern remains same.
>> > I am also awaiting a response from ARM maintainers before proceeding.
>> > Just to be more clear, this
>> > concern was pointed out in one of my previous-and-some-what-relative
>> > patch about console-verbose
>> > level restoration issue.
>> >> Florian
>> Gentle reminder for Arm maintainers.
>> If concern can be taken care from your side in different ways then bug
>> can be resolved.
>
> I've recently started trying to untangle much of our fatal trap handling
> code so that the decision between user-mode and kernel-mode actions is
> explicit in the caller, rather than buried deep in the bowels of some
> callchain. The aim is also to remove arm64_notify_die() entirely, which
> is a complete maze of crap that ultimately depends on what kgdb does in
> some cases!
>
> With that out of the way, die() itself could probably be simplified so that
> it (a) avoids the notifier chain [which is useless for us] and (b) is only
> intended to be called for kernel contexts, i.e. as a wrapper around a
> panic_on_oops check.
>
> But this needn't affect your patch, which seems to be a small step in the
> right direction. I'll pick it up as part of my series when I send it out,
> if that's alright with you? I don't think any of this is especially urgent.
>
> Will
Thanks Will for your reply. Issue should be just addressed. If it is
being taken care from
your end in better way, no issue from our end too. Please intimate
once changes are
available in kernel release so that we can pick it.

Regards,
hari

      reply	other threads:[~2018-08-22  6:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 11:03 [PATCH] arm64: fix for bad_mode() handler to always result in panic Hari Vyas
2018-08-07 12:27 ` Greg KH
2018-08-08 18:18   ` Hari Vyas
2018-08-08 18:23     ` Florian Fainelli
2018-08-10 16:46       ` Hari Vyas
2018-08-21 14:16         ` Hari Vyas
2018-08-21 17:38           ` Will Deacon
2018-08-22  6:31             ` Hari Vyas [this message]

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=CAM5rFu-dbtmc2buJAOQQg+vGSPvu4coxz7JXg-biiMBNAn4Mvg@mail.gmail.com \
    --to=hari.vyas@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).