On Thu, Feb 15, 2018 at 10:44:44AM -0700, Jerry Hoemann wrote:
> Is your desire to remove of the firmware callback/spinlock in hpwdt_pretimeout
> related to David Woodhouse patch set:
That's the work that made us find this code, but no, even without that,
code like that is entirely dodgy. NMI code
* Jerry Hoemann wrote:
> On Thu, Feb 15, 2018 at 12:17:04AM +0100, Ingo Molnar wrote:
> >
> > * Jerry Hoemann wrote:
> >
> > >
> > > Ingo,
> > >
> > > I have a patch set under review that brings hpwdt into compliance
> > > with the watchdog core.
> > >
> > > One of the changes removes the
On Thu, Feb 15, 2018 at 12:17:04AM +0100, Ingo Molnar wrote:
>
> * Jerry Hoemann wrote:
>
> >
> > Ingo,
> >
> > I have a patch set under review that brings hpwdt into compliance
> > with the watchdog core.
> >
> > One of the changes removes the callback into firmware in hpwdt_pretimeout
> > a
* Jerry Hoemann wrote:
>
> Ingo,
>
> I have a patch set under review that brings hpwdt into compliance
> with the watchdog core.
>
> One of the changes removes the callback into firmware in hpwdt_pretimeout
> and its associated spinlock.
>
> https://lkml.org/lkml/2018/2/12/30
drivers/watch
Ingo,
I have a patch set under review that brings hpwdt into compliance
with the watchdog core.
One of the changes removes the callback into firmware in hpwdt_pretimeout
and its associated spinlock.
https://lkml.org/lkml/2018/2/12/30
I will add you to the CC list of the next version of the set
* Peter Zijlstra wrote:
> On Wed, Feb 14, 2018 at 10:31:59AM +0100, Ingo Molnar wrote:
> > Because in this particular case it does not appear to be so: the reason for
> > the
> > BIOS/firmware call appears to be to determine how we nmi_panic() after
> > receiving
> > an NMI that no other NMI
+ Jerry
On Wed, Feb 14, 2018 at 10:31:59AM +0100, Ingo Molnar wrote:
>
> * Tim Chen wrote:
>
> > Dave Hansen and I had some discussions on how to handle the nested NMI and
> > firmware calls. We thought of using a per cpu counter to record the
> > nesting
> > call depth and toggle IBRS appr
On Wed, Feb 14, 2018 at 10:31:59AM +0100, Ingo Molnar wrote:
> Because in this particular case it does not appear to be so: the reason for
> the
> BIOS/firmware call appears to be to determine how we nmi_panic() after
> receiving
> an NMI that no other NMI handler handled: with a passive-aggres
8 matches
Mail list logo