From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave@sr71.net>,
hpa@zytor.com, tglx@linutronix.de, torvalds@linux-foundation.org,
linux-kernel@vger.kernel.org, dwmw@amazon.co.uk,
linux-tip-commits@vger.kernel.org,
Arjan van de Ven <arjan@infradead.org>,
Jerry Hoemann <jerry.hoemann@hpe.com>
Subject: Re: [PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from NMI context
Date: Wed, 14 Feb 2018 10:44:05 +0100 [thread overview]
Message-ID: <20180214094404.GA18349@pd.tnic> (raw)
In-Reply-To: <20180214093159.mdzfupne547bi5qx@gmail.com>
+ Jerry
On Wed, Feb 14, 2018 at 10:31:59AM +0100, Ingo Molnar wrote:
>
> * Tim Chen <tim.c.chen@linux.intel.com> 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 appropriately for the depth 0->1 and 1->0 transition.
> > Will this change be sufficient?
>
> Yeah, so I think the first question should be: does the firmware call from NMI
> context make sense to begin with?
>
> 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-aggressive "I don't know"
> panic message or with a slightly more informative panic message.
>
> That's not a real value-add to users - so we can avoid all these complications by
> applying the patch below:
>
> drivers/watchdog/hpwdt.c | 30 ++++--------------------------
> 1 file changed, 4 insertions(+), 26 deletions(-)
>
> As a bonus the spinlock use can be removed as well.
>
> Thanks,
>
> Ingo
>
> ====================>
> From b038428a739a3fcf0b9678305c131f60af7422ca Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@kernel.org>
> Date: Wed, 14 Feb 2018 10:24:41 +0100
> Subject: [PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from
> NMI context
>
> Taking a spinlock and calling into the firmware are problematic things to
> do from NMI callbacks.
>
> It also seems completely pointless in this particular case:
>
> - cmn_regs is updated by the firmware call in the hpwdt_pretimeout() NMI
> callback, but there's almost no use for it: we use it only to determine
> whether to panic with an 'unknown NMI' or a slightly more descriptive
> message.
>
> - cmn_regs and rom_lock is not used anywhere else, other than early detection
> of the firmware capability.
>
> So remove rom_lock, make the cmn_regs call from the detection routine only,
> and thus make the NMI callback a lot more robust.
>
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
> drivers/watchdog/hpwdt.c | 30 ++++--------------------------
> 1 file changed, 4 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> index f1f00dfc0e68..2544fe482fe3 100644
> --- a/drivers/watchdog/hpwdt.c
> +++ b/drivers/watchdog/hpwdt.c
> @@ -150,9 +150,7 @@ static unsigned int hpwdt_nmi_decoding;
> static unsigned int allow_kdump = 1;
> static unsigned int is_icru;
> static unsigned int is_uefi;
> -static DEFINE_SPINLOCK(rom_lock);
> static void *cru_rom_addr;
> -static struct cmn_registers cmn_regs;
>
> extern asmlinkage void asminline_call(struct cmn_registers *pi86Regs,
> unsigned long *pRomEntry);
> @@ -225,6 +223,7 @@ static int cru_detect(unsigned long map_entry,
> unsigned long physical_bios_base = 0;
> unsigned long physical_bios_offset = 0;
> int retval = -ENODEV;
> + struct cmn_registers cmn_regs = { };
>
> bios32_map = ioremap(map_entry, (2 * PAGE_SIZE));
>
> @@ -486,32 +485,18 @@ static int hpwdt_my_nmi(void)
> */
> static int hpwdt_pretimeout(unsigned int ulReason, struct pt_regs *regs)
> {
> - unsigned long rom_pl;
> - static int die_nmi_called;
> -
> if (!hpwdt_nmi_decoding)
> return NMI_DONE;
>
> if ((ulReason == NMI_UNKNOWN) && !hpwdt_my_nmi())
> return NMI_DONE;
>
> - spin_lock_irqsave(&rom_lock, rom_pl);
> - if (!die_nmi_called && !is_icru && !is_uefi)
> - asminline_call(&cmn_regs, cru_rom_addr);
> - die_nmi_called = 1;
> - spin_unlock_irqrestore(&rom_lock, rom_pl);
> -
> if (allow_kdump)
> hpwdt_stop();
>
> - if (!is_icru && !is_uefi) {
> - if (cmn_regs.u1.ral == 0) {
> - nmi_panic(regs, "An NMI occurred, but unable to determine source.\n");
> - return NMI_HANDLED;
> - }
> - }
> - nmi_panic(regs, "An NMI occurred. Depending on your system the reason "
> - "for the NMI is logged in any one of the following "
> + nmi_panic(regs,
> + "An NMI occurred. Depending on your system the reason "
> + "for the NMI might be logged in any one of the following "
> "resources:\n"
> "1. Integrated Management Log (IML)\n"
> "2. OA Syslog\n"
> @@ -744,13 +729,6 @@ static int hpwdt_init_nmi_decoding(struct pci_dev *dev)
> HPWDT_ARCH);
> return retval;
> }
> -
> - /*
> - * We know this is the only CRU call we need to make so lets keep as
> - * few instructions as possible once the NMI comes in.
> - */
> - cmn_regs.u1.rah = 0x0D;
> - cmn_regs.u1.ral = 0x02;
> }
>
> /*
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2018-02-14 9:44 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-10 23:39 [PATCH v2 0/6] Spectre v2 updates David Woodhouse
2018-02-10 23:39 ` [PATCH v2 1/6] x86/speculation: Update Speculation Control microcode blacklist David Woodhouse
2018-02-11 12:08 ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-02-12 9:50 ` [PATCH v2 1/6] " Darren Kenny
2018-02-12 14:16 ` David Woodhouse
2018-02-12 14:32 ` Thomas Gleixner
2018-02-10 23:39 ` [PATCH v2 2/6] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()" David Woodhouse
2018-02-11 12:09 ` [tip:x86/pti] " tip-bot for David Woodhouse
2018-02-13 8:58 ` tip-bot for David Woodhouse
2018-02-13 9:41 ` Peter Zijlstra
2018-02-13 11:28 ` Ingo Molnar
2018-02-13 13:28 ` Peter Zijlstra
2018-02-13 13:38 ` Ingo Molnar
2018-02-13 15:26 ` [tip:x86/pti] x86/speculation: Add <asm/msr-index.h> dependency tip-bot for Peter Zijlstra
2018-02-15 0:28 ` tip-bot for Peter Zijlstra
2018-02-10 23:39 ` [PATCH v2 3/6] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range() David Woodhouse
2018-02-11 12:09 ` [tip:x86/pti] KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods tip-bot for David Woodhouse
2018-02-13 8:58 ` tip-bot for David Woodhouse
2018-02-10 23:39 ` [PATCH v2 4/6] X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs David Woodhouse
2018-02-11 12:10 ` [tip:x86/pti] " tip-bot for KarimAllah Ahmed
2018-02-13 8:59 ` tip-bot for KarimAllah Ahmed
2018-02-10 23:39 ` [PATCH v2 5/6] KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap David Woodhouse
2018-02-11 10:19 ` Ingo Molnar
[not found] ` <1518345844.3677.365.camel@amazon.co.uk>
2018-02-11 10:55 ` Ingo Molnar
2018-02-11 12:10 ` [tip:x86/pti] " tip-bot for KarimAllah Ahmed
2018-02-13 8:59 ` tip-bot for KarimAllah Ahmed
2018-02-10 23:39 ` [PATCH v2 6/6] x86/speculation: Use IBRS if available before calling into firmware David Woodhouse
2018-02-11 11:46 ` Ingo Molnar
2018-02-11 10:41 ` [PATCH v2 0/6] Spectre v2 updates Ingo Molnar
2018-02-11 15:19 ` [PATCH v2.1] x86/speculation: Use IBRS if available before calling into firmware David Woodhouse
2018-02-11 18:50 ` [PATCH] x86/speculation: Clean up various Spectre related details Ingo Molnar
2018-02-11 19:25 ` David Woodhouse
2018-02-11 19:43 ` Ingo Molnar
2018-02-12 15:30 ` David Woodhouse
2018-02-13 8:04 ` Ingo Molnar
2018-02-11 19:19 ` [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware tip-bot for David Woodhouse
2018-02-12 5:59 ` afzal mohammed
2018-02-12 16:30 ` David Woodhouse
2018-02-12 10:22 ` Ingo Molnar
2018-02-12 11:50 ` Peter Zijlstra
2018-02-12 12:27 ` David Woodhouse
2018-02-12 13:06 ` Peter Zijlstra
2018-02-13 7:58 ` Ingo Molnar
2018-02-12 12:28 ` Peter Zijlstra
2018-02-12 16:13 ` Dave Hansen
2018-02-12 16:58 ` Peter Zijlstra
2018-02-13 7:55 ` Ingo Molnar
2018-02-14 1:49 ` Tim Chen
2018-02-14 8:56 ` Peter Zijlstra
2018-02-14 8:57 ` Peter Zijlstra
2018-02-14 19:20 ` Tim Chen
2018-02-14 23:19 ` Ingo Molnar
2018-02-15 2:01 ` Tim Chen
2018-02-14 9:31 ` [PATCH] watchdog: hpwdt: Remove spinlock acquire and BIOS calls from NMI context Ingo Molnar
2018-02-14 9:38 ` Peter Zijlstra
2018-02-14 10:39 ` Ingo Molnar
2018-02-14 9:44 ` Borislav Petkov [this message]
2018-02-14 18:13 ` Jerry Hoemann
2018-02-14 23:17 ` Ingo Molnar
2018-02-15 17:44 ` Jerry Hoemann
2018-02-15 19:02 ` Ingo Molnar
2018-02-15 19:48 ` Peter Zijlstra
2018-02-16 18:44 ` [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware Tim Chen
2018-02-16 19:16 ` David Woodhouse
2018-02-16 23:46 ` Tim Chen
2018-02-17 10:26 ` Ingo Molnar
2018-02-19 9:20 ` Peter Zijlstra
2018-02-19 9:29 ` David Woodhouse
2018-02-19 9:39 ` Ingo Molnar
2018-02-19 9:44 ` David Woodhouse
2018-02-19 10:08 ` Peter Zijlstra
2018-02-19 9:36 ` Ingo Molnar
2018-02-12 8:27 ` [PATCH v2 0/6] Spectre v2 updates Paolo Bonzini
2018-02-13 7:59 ` Ingo Molnar
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=20180214094404.GA18349@pd.tnic \
--to=bp@alien8.de \
--cc=arjan@infradead.org \
--cc=dave@sr71.net \
--cc=dwmw@amazon.co.uk \
--cc=hpa@zytor.com \
--cc=jerry.hoemann@hpe.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.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 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.