linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
Date: Fri, 18 Nov 2016 13:48:48 +0000	[thread overview]
Message-ID: <20161118134847.GO13470@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1611181430070.3615@nanos>

On Fri, Nov 18, 2016 at 02:42:15PM +0100, Thomas Gleixner wrote:
> On Fri, 18 Nov 2016, Will Deacon wrote:
> > On Fri, Nov 18, 2016 at 02:11:58PM +0100, Thomas Gleixner wrote:
> > > But it's guaranteed that cpuhp_setup_state() will not return before the
> > > callback has been invoked on each online cpu.
> > 
> > Ok, that's good.
> > 
> > > If cpus are not yet online when that code is invoked, then it's the same
> > > behaviour as before. It will be invoked when the cpu comes online.
> > 
> > Just to check, but what stops a CPU from coming online between the call
> > to cpuhp_setup_state and the call to cpuhp_remove_state_nocalls in the
> > case of failure (debug_err_mask isn't empty)?
> 
> Indeed! I missed that part. So we still need a get/put_online_cpus()
> protection around all of this.

Yes, that should do it.

> Just for curiosity sake. Wouldn't it be simpler and less error prone to
> make the ARM_DBG_READ/WRITE macros use the exception table and handle that
> in the undefined instruction handler to avoid this hook dance?

That would be an option, but it's only the reset sequence that could
generate this fault so it's simpler to isolate it there. We'd also have
to take into account SMP if we toggle the handler in the READ/WRITE
accessors, since the fault handler framework is system-wide as opposed
to per-cpu. The whole thing is grotty as hell.

Will

  reply	other threads:[~2016-11-18 13:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20161117183541.8588-1-bigeasy@linutronix.de>
2016-11-17 18:35 ` [PATCH 07/20] pci/xgene-msi: Convert to hotplug state machine Sebastian Andrzej Siewior
2016-11-17 18:35 ` [PATCH 14/20] arm/bL_switcher: " Sebastian Andrzej Siewior
2016-11-17 18:35 ` [PATCH 15/20] ARM/hw_breakpoint: " Sebastian Andrzej Siewior
2016-11-18 12:04   ` Will Deacon
2016-11-18 13:11     ` Thomas Gleixner
2016-11-18 13:29       ` Will Deacon
2016-11-18 13:42         ` Thomas Gleixner
2016-11-18 13:48           ` Will Deacon [this message]
2016-11-18 13:59             ` Thomas Gleixner
2016-11-18 14:11               ` Will Deacon
2017-01-02 14:15   ` Linus Walleij
2017-01-02 14:34     ` Linus Walleij
2017-01-02 15:00       ` Russell King - ARM Linux
2017-01-02 20:15         ` Linus Walleij
2017-01-03  9:33           ` Mark Rutland
2017-01-04 11:27             ` Sebastian Andrzej Siewior
2017-01-04 13:56             ` Mark Rutland
2017-01-04 14:32               ` Will Deacon
2017-01-05 15:57                 ` Mark Rutland
2017-01-05 15:26               ` Linus Walleij
2017-01-05 17:14                 ` Mark Rutland

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=20161118134847.GO13470@arm.com \
    --to=will.deacon@arm.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).