All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xunlei Pang <xpang@redhat.com>
To: Borislav Petkov <bp@alien8.de>, xlpang@redhat.com
Cc: Prarit Bhargava <prarit@redhat.com>,
	Kiyoshi Ueda <k-ueda@ct.jp.nec.com>,
	Tony Luck <tony.luck@intel.com>,
	x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Junichi Nomura <j-nomura@ce.jp.nec.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Dave Young <dyoung@redhat.com>
Subject: Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic
Date: Thu, 16 Feb 2017 13:36:37 +0800	[thread overview]
Message-ID: <58A53A65.3000405@redhat.com> (raw)
In-Reply-To: <20170126064400.wfsn5pzxnpi6gcuk@pd.tnic>

On 01/26/2017 at 02:44 PM, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
>> The hardware machine check is hard to reproduce, but the mce code of
>> RHEL7 is quite the same as that of tip/master, anyway we are able to
>> inject software mce to reproduce it.
> Please give me your exact steps so that I can try to reproduce it here
> too.
>

Hi Borislav,

I tried to use qemu to inject SRAO("mce -b 0 0 0xb100000000000000 0x5 0x0 0x0"),
it works well in 1st kernel, but it doesn't work for 1st kernel after kdump boots(seems
the cpus remain in 1st kernel don't respond to the simulated broadcasting mce).

But in theory, we know cpus belong to kdump kernel can't respond to the
old mce handler, so a single SRAO injection in 1st kernel should be similar.
For example, I used "... -smp 2 -cpu Haswell" to launch a simulation with broadcast
mce supported, and inject SRAO to cpu0 only through qemu monitor
"mce 0 0 0xb100000000000000 0x5 0x0 0x0", cpu0 will timeout/panic and reboot
the machine as follows(running on linux-4.9):
  Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
  Kernel Offset: disabled
  Rebooting in 30 seconds..

Regards,
Xunlei

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Xunlei Pang <xpang@redhat.com>
To: Borislav Petkov <bp@alien8.de>, xlpang@redhat.com
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	kexec@lists.infradead.org, Tony Luck <tony.luck@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Dave Young <dyoung@redhat.com>,
	Prarit Bhargava <prarit@redhat.com>,
	Junichi Nomura <j-nomura@ce.jp.nec.com>,
	Kiyoshi Ueda <k-ueda@ct.jp.nec.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic
Date: Thu, 16 Feb 2017 13:36:37 +0800	[thread overview]
Message-ID: <58A53A65.3000405@redhat.com> (raw)
In-Reply-To: <20170126064400.wfsn5pzxnpi6gcuk@pd.tnic>

On 01/26/2017 at 02:44 PM, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
>> The hardware machine check is hard to reproduce, but the mce code of
>> RHEL7 is quite the same as that of tip/master, anyway we are able to
>> inject software mce to reproduce it.
> Please give me your exact steps so that I can try to reproduce it here
> too.
>

Hi Borislav,

I tried to use qemu to inject SRAO("mce -b 0 0 0xb100000000000000 0x5 0x0 0x0"),
it works well in 1st kernel, but it doesn't work for 1st kernel after kdump boots(seems
the cpus remain in 1st kernel don't respond to the simulated broadcasting mce).

But in theory, we know cpus belong to kdump kernel can't respond to the
old mce handler, so a single SRAO injection in 1st kernel should be similar.
For example, I used "... -smp 2 -cpu Haswell" to launch a simulation with broadcast
mce supported, and inject SRAO to cpu0 only through qemu monitor
"mce 0 0 0xb100000000000000 0x5 0x0 0x0", cpu0 will timeout/panic and reboot
the machine as follows(running on linux-4.9):
  Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
  Kernel Offset: disabled
  Rebooting in 30 seconds..

Regards,
Xunlei

  reply	other threads:[~2017-02-16  5:35 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23  8:01 [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic Xunlei Pang
2017-01-23  8:01 ` Xunlei Pang
2017-01-23 12:51 ` Borislav Petkov
2017-01-23 12:51   ` Borislav Petkov
2017-01-23 13:35   ` Xunlei Pang
2017-01-23 13:35     ` Xunlei Pang
2017-01-23 14:50     ` Borislav Petkov
2017-01-23 14:50       ` Borislav Petkov
2017-01-23 17:40       ` Luck, Tony
2017-01-23 17:40         ` Luck, Tony
2017-01-23 17:51         ` Borislav Petkov
2017-01-23 17:51           ` Borislav Petkov
2017-01-23 18:01           ` Luck, Tony
2017-01-23 18:01             ` Luck, Tony
2017-01-23 18:14             ` Borislav Petkov
2017-01-23 18:14               ` Borislav Petkov
2017-01-24  2:33               ` Xunlei Pang
2017-01-24  2:33                 ` Xunlei Pang
2017-01-24  1:46           ` Xunlei Pang
2017-01-24  1:46             ` Xunlei Pang
2017-01-24  1:51             ` Xunlei Pang
2017-01-24  1:51               ` Xunlei Pang
2017-01-24  1:27       ` Xunlei Pang
2017-01-24  1:27         ` Xunlei Pang
2017-01-24 12:22         ` Borislav Petkov
2017-01-24 12:22           ` Borislav Petkov
2017-01-26  6:30           ` Xunlei Pang
2017-01-26  6:30             ` Xunlei Pang
2017-01-26  6:44             ` Borislav Petkov
2017-01-26  6:44               ` Borislav Petkov
2017-02-16  5:36               ` Xunlei Pang [this message]
2017-02-16  5:36                 ` Xunlei Pang
2017-02-16 10:18                 ` Borislav Petkov
2017-02-16 10:18                   ` Borislav Petkov
2017-02-16 11:52                   ` Xunlei Pang
2017-02-16 11:52                     ` Xunlei Pang
2017-02-16 12:22                     ` Borislav Petkov
2017-02-16 12:22                       ` Borislav Petkov
2017-02-17  1:53                       ` Xunlei Pang
2017-02-17  1:53                         ` Xunlei Pang
2017-02-17  9:07                         ` Borislav Petkov
2017-02-17  9:07                           ` Borislav Petkov
2017-02-17 16:21                           ` Xunlei Pang
2017-02-17 16:21                             ` Xunlei Pang
2017-02-21 18:20                             ` Luck, Tony
2017-02-21 18:20                               ` Luck, Tony
2017-02-22  5:50                               ` Xunlei Pang
2017-02-22  5:50                                 ` Xunlei Pang

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=58A53A65.3000405@redhat.com \
    --to=xpang@redhat.com \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=k-ueda@ct.jp.nec.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=prarit@redhat.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xlpang@redhat.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.