All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Tony Lindgren <tony@atomide.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>,
	linux-omap@vger.kernel.org, patchwork-lst@pengutronix.de,
	linux-arm-kernel@lists.infradead.org,
	Lucas Stach <l.stach@pengutronix.de>
Subject: Re: [PATCH v2 1/3] ARM: catch pending imprecise abort on unmask
Date: Thu, 15 Oct 2015 17:06:31 +0100	[thread overview]
Message-ID: <20151015160631.GI32536@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20151015153915.GO10113@atomide.com>

On Thu, Oct 15, 2015 at 08:39:15AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [151015 08:37]:
> > On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > > Install a non-faulting handler just before unmasking imprecise aborts
> > > and switch back to the regular one after unmasking is done.
> > > 
> > > This catches any pending imprecise abort that the firmware/bootloader
> > > may have left behind that would normally crash the kernel at that point.
> > > As there are apparently a lot of bootlaoders out there that do such a
> > > thing it makes sense to handle it in the common startup code.
> > > 
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > 
> > Much better.  Please feel free to add it to the patch system, thanks.
> > 
> > I think, given that the original seems to be breaking platforms, this
> > patch needs to go into -rc kernels, right?
> 
> Hmm do we still see a trace where the issue happened though with this
> one?

That's not the intention of this specific patch.

This is solely to detect the bootloader induced imprecise exception,
nothing more.  A backtrace for that won't be useful in any shape or
form - in fact, the backtrace will be well known (it'll be from the
site where the imprecise exceptions are unmasked.)

Any imprecise exception which happens after this will be handled in
the normal way: it'll raise a kernel oops, and that will have all the
details that a kernel oops normally has.

The difference is, rather than the boot loader provoking the kernel to
oops at this point, we're able to report the event and continue on.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] ARM: catch pending imprecise abort on unmask
Date: Thu, 15 Oct 2015 17:06:31 +0100	[thread overview]
Message-ID: <20151015160631.GI32536@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20151015153915.GO10113@atomide.com>

On Thu, Oct 15, 2015 at 08:39:15AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [151015 08:37]:
> > On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > > Install a non-faulting handler just before unmasking imprecise aborts
> > > and switch back to the regular one after unmasking is done.
> > > 
> > > This catches any pending imprecise abort that the firmware/bootloader
> > > may have left behind that would normally crash the kernel at that point.
> > > As there are apparently a lot of bootlaoders out there that do such a
> > > thing it makes sense to handle it in the common startup code.
> > > 
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > 
> > Much better.  Please feel free to add it to the patch system, thanks.
> > 
> > I think, given that the original seems to be breaking platforms, this
> > patch needs to go into -rc kernels, right?
> 
> Hmm do we still see a trace where the issue happened though with this
> one?

That's not the intention of this specific patch.

This is solely to detect the bootloader induced imprecise exception,
nothing more.  A backtrace for that won't be useful in any shape or
form - in fact, the backtrace will be well known (it'll be from the
site where the imprecise exceptions are unmasked.)

Any imprecise exception which happens after this will be handled in
the normal way: it'll raise a kernel oops, and that will have all the
details that a kernel oops normally has.

The difference is, rather than the boot loader provoking the kernel to
oops at this point, we're able to report the event and continue on.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2015-10-15 16:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15 10:32 [PATCH v2 0/3] ARM: handle imprecise aborts from firmware in common code Lucas Stach
2015-10-15 10:32 ` Lucas Stach
2015-10-15 10:32 ` [PATCH v2 1/3] ARM: catch pending imprecise abort on unmask Lucas Stach
2015-10-15 10:32   ` Lucas Stach
2015-10-15 15:32   ` Russell King - ARM Linux
2015-10-15 15:32     ` Russell King - ARM Linux
2015-10-15 15:39     ` Tony Lindgren
2015-10-15 15:39       ` Tony Lindgren
2015-10-15 16:06       ` Russell King - ARM Linux [this message]
2015-10-15 16:06         ` Russell King - ARM Linux
2015-10-15 16:23         ` Tony Lindgren
2015-10-15 16:23           ` Tony Lindgren
2015-10-16  8:21     ` Lucas Stach
2015-10-16  8:21       ` Lucas Stach
2015-10-19 12:41     ` Lucas Stach
2015-10-19 12:41       ` Lucas Stach
2015-10-15 10:32 ` [PATCH v2 2/3] ARM: OMAP2+: remove custom abort handler for t410 Lucas Stach
2015-10-15 10:32   ` Lucas Stach
2015-11-12 13:32   ` Lucas Stach
2015-11-12 13:32     ` Lucas Stach
2015-11-12 17:51     ` Tony Lindgren
2015-11-12 17:51       ` Tony Lindgren
2015-10-15 10:32 ` [PATCH v2 3/3] ARM: BCM5301X: remove workaround imprecise abort fault handler Lucas Stach
2015-10-15 10:32   ` Lucas Stach
2015-11-12 13:37   ` Lucas Stach
2015-11-12 17:54     ` Hauke Mehrtens
2015-11-25  0:01   ` Florian Fainelli
2015-11-25  0:01     ` Florian Fainelli
2015-10-16 19:11 ` [PATCH v2 0/3] ARM: handle imprecise aborts from firmware in common code Tyler Baker
2015-10-16 19:11   ` Tyler Baker

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=20151015160631.GI32536@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=hauke@hauke-m.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=patchwork-lst@pengutronix.de \
    --cc=tony@atomide.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.