linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Andy Lutomirski <luto@kernel.org>,
	Tony Luck <tony.luck@intel.com>, x86-ml <x86@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] #MC mess
Date: Tue, 18 Feb 2020 13:11:58 -0500	[thread overview]
Message-ID: <20200218131158.693eeefc@gandalf.local.home> (raw)
In-Reply-To: <20200218173150.GK14449@zn.tnic>

On Tue, 18 Feb 2020 18:31:50 +0100
Borislav Petkov <bp@alien8.de> wrote:

> Ok,
> 
> so Peter raised this question on IRC today, that the #MC handler needs
> to disable all kinds of tracing/kprobing and etc exceptions happening
> while handling an #MC. And I guess we can talk about supporting some
> exceptions but #MC is usually nasty enough to not care about tracing
> when former happens.

What's the issue with tracing? Does this affect the tracing done by the
edac_mc_handle_error code?

It has a trace event in it, that the rasdaemon uses.

> 
> So how about this trivial first stab of using the big hammer and simply
> turning off stuff? The nmi_enter()/nmi_exit() thing still needs debating
> because ist_enter() already does rcu_nmi_enter() and I'm not sure
> whether any of the context tracking would still be ok with that.
> 
> Anything else I'm missing? It is likely...
> 
> Thx.
> 
> ---
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 2c4f949611e4..6dff97c53310 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -1214,7 +1214,7 @@ static void __mc_scan_banks(struct mce *m, struct mce *final,
>   * MCE broadcast. However some CPUs might be broken beyond repair,
>   * so be always careful when synchronizing with others.
>   */
> -void do_machine_check(struct pt_regs *regs, long error_code)
> +void notrace do_machine_check(struct pt_regs *regs, long error_code)
>  {
>  	DECLARE_BITMAP(valid_banks, MAX_NR_BANKS);
>  	DECLARE_BITMAP(toclear, MAX_NR_BANKS);
> @@ -1251,6 +1251,10 @@ void do_machine_check(struct pt_regs *regs, long error_code)
>  	if (__mc_check_crashing_cpu(cpu))
>  		return;
>  
> +	hw_breakpoint_disable();
> +	static_key_disable(&__tracepoint_read_msr.key);

I believe static_key_disable() sleeps, and does all kinds of crazing
things (like update the code).

-- Steve

> +	tracing_off();
> +
>  	ist_enter(regs);
>  
>  	this_cpu_inc(mce_exception_count);
> @@ -1360,6 +1364,7 @@ void do_machine_check(struct pt_regs *regs, long error_code)
>  	ist_exit(regs);
>  }
>  EXPORT_SYMBOL_GPL(do_machine_check);
> +NOKPROBE_SYMBOL(do_machine_check);
>  
>  #ifndef CONFIG_MEMORY_FAILURE
>  int memory_failure(unsigned long pfn, int flags)
> 


  reply	other threads:[~2020-02-18 18:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-18 17:31 [RFC] #MC mess Borislav Petkov
2020-02-18 18:11 ` Steven Rostedt [this message]
2020-02-18 19:50   ` Borislav Petkov
2020-02-18 20:08     ` Steven Rostedt
2020-02-18 20:30       ` Peter Zijlstra
2020-02-18 20:52       ` Borislav Petkov
2020-02-18 18:20 ` Luck, Tony
2020-02-18 19:51   ` Borislav Petkov
2020-02-18 19:54     ` Luck, Tony
2020-02-18 20:00       ` Borislav Petkov
2020-02-18 20:05         ` Luck, Tony
2020-02-18 20:02   ` Peter Zijlstra
2020-02-18 20:09     ` Borislav Petkov
2020-02-18 20:11     ` Luck, Tony
2020-02-18 20:34       ` Peter Zijlstra
2020-02-18 21:49         ` Peter Zijlstra
2020-02-18 21:53           ` Peter Zijlstra
2020-02-18 22:41             ` Frederic Weisbecker
2020-02-18 22:40           ` Frederic Weisbecker
2020-02-18 23:17     ` Andy Lutomirski
2020-02-18 23:10   ` Andy Lutomirski
2020-02-18 23:17     ` Steven Rostedt
2020-02-19  0:15 ` Andy Lutomirski
2020-02-19  8:15   ` Peter Zijlstra
2020-02-19 14:21     ` Steven Rostedt
2020-02-19 14:43       ` Borislav Petkov
2020-02-19 15:05       ` Peter Zijlstra
2020-02-19 15:20         ` Andy Lutomirski

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=20200218131158.693eeefc@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.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).