Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1283447 > unrolled thread

[Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

Back to article view | Back to linux.kernel

Contents

  [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process. Ashok Raj <ashok.raj@intel.com> - 2015-12-04 00:20 +0100
    Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Greg KH <greg@kroah.com> - 2015-12-04 00:40 +0100
    Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Borislav Petkov <bp@alien8.de> - 2015-12-04 15:40 +0100
      Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. "Raj, Ashok" <ashok.raj@intel.com> - 2015-12-04 17:20 +0100
        Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Borislav Petkov <bp@alien8.de> - 2015-12-04 18:00 +0100
          RE: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. "Luck, Tony" <tony.luck@intel.com> - 2015-12-04 18:30 +0100
            Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Borislav Petkov <bp@alien8.de> - 2015-12-04 18:40 +0100
              RE: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. "Luck, Tony" <tony.luck@intel.com> - 2015-12-04 19:00 +0100
                Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Borislav Petkov <bp@alien8.de> - 2015-12-04 19:10 +0100
                  RE: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. "Luck, Tony" <tony.luck@intel.com> - 2015-12-04 19:40 +0100
                    Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Borislav Petkov <bp@alien8.de> - 2015-12-04 20:40 +0100
                Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Andy Lutomirski <luto@amacapital.net> - 2015-12-04 23:40 +0100
                  Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. "Raj, Ashok" <ashok.raj@intel.com> - 2015-12-05 00:10 +0100
                    Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in  mce rendezvous process. Andy Lutomirski <luto@amacapital.net> - 2015-12-05 00:20 +0100

#1283447 — [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

Linux has logical cpu offline capability. That can be triggered by:

# echo 0 > /sys/devices/system/cpu/cpuX/online

In Intel Architecture, MCE's are broadcasted to all CPUs in the system.

This includes the CPUs marked offline by Linux. Unless the CPU's were removed
via an ACPI notification, in which case the cpu's are removed from the
cpu_present_map.

This patch ensures offline CPU's don't participate in MCE rendezvous, but
simply perform clearing some status bits to ensure a second MCE wont cause
automatic shutdown.

Without the patch, mce_start will increment mce_callin, but mce_start would
wait for all online_cpus. So offline cpu's should avoid participating in the
rendezvous process.

Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index c5b0d56..82a0c8b 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -998,6 +998,7 @@ void do_machine_check(struct pt_regs *regs, long error_code)
 	u64 recover_paddr = ~0ull;
 	int flags = MF_ACTION_REQUIRED;
 	int lmce = 0;
+	unsigned int cpu = smp_processor_id();
 
 	ist_enter(regs);
 
@@ -1008,6 +1009,14 @@ void do_machine_check(struct pt_regs *regs, long error_code)
 
 	mce_gather_info(&m, regs);
 
+	/*
+	 * if this cpu is offline, just bail out.
+	 * TBD: looking into adding any logs this offline CPU might have,
+	 * to be collected and reported by the rendezvous master.
+	 */
+	if (cpu_is_offline(cpu) && (m.mcgstatus & MCG_STATUS_RIPV))
+		goto out;
+
 	final = this_cpu_ptr(&mces_seen);
 	*final = m;
 
@@ -1142,8 +1151,8 @@ void do_machine_check(struct pt_regs *regs, long error_code)
 
 	if (worst > 0)
 		mce_report_event(regs);
-	mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
 out:
+	mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
 	sync_core();
 
 	if (recover_paddr == ~0ull)
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1283453 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Thu, Dec 03, 2015 at 07:16:10PM -0500, Ashok Raj wrote:
> Linux has logical cpu offline capability. That can be triggered by:
> 
> # echo 0 > /sys/devices/system/cpu/cpuX/online
> 
> In Intel Architecture, MCE's are broadcasted to all CPUs in the system.
> 
> This includes the CPUs marked offline by Linux. Unless the CPU's were removed
> via an ACPI notification, in which case the cpu's are removed from the
> cpu_present_map.
> 
> This patch ensures offline CPU's don't participate in MCE rendezvous, but
> simply perform clearing some status bits to ensure a second MCE wont cause
> automatic shutdown.
> 
> Without the patch, mce_start will increment mce_callin, but mce_start would
> wait for all online_cpus. So offline cpu's should avoid participating in the
> rendezvous process.
> 
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283866 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Thu, Dec 03, 2015 at 07:16:10PM -0500, Ashok Raj wrote:
> Linux has logical cpu offline capability. That can be triggered by:
> 
> # echo 0 > /sys/devices/system/cpu/cpuX/online
> 
> In Intel Architecture, MCE's are broadcasted to all CPUs in the system.
> 
> This includes the CPUs marked offline by Linux. Unless the CPU's were removed
> via an ACPI notification, in which case the cpu's are removed from the
> cpu_present_map.
> 
> This patch ensures offline CPU's don't participate in MCE rendezvous, but
> simply perform clearing some status bits to ensure a second MCE wont cause
> automatic shutdown.
> 
> Without the patch, mce_start will increment mce_callin, but mce_start would
> wait for all online_cpus. So offline cpu's should avoid participating in the
> rendezvous process.
> 
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
> index c5b0d56..82a0c8b 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -998,6 +998,7 @@ void do_machine_check(struct pt_regs *regs, long error_code)
>  	u64 recover_paddr = ~0ull;
>  	int flags = MF_ACTION_REQUIRED;
>  	int lmce = 0;
> +	unsigned int cpu = smp_processor_id();
>  
>  	ist_enter(regs);
>  
> @@ -1008,6 +1009,14 @@ void do_machine_check(struct pt_regs *regs, long error_code)
>  
>  	mce_gather_info(&m, regs);
>  
> +	/*
> +	 * if this cpu is offline, just bail out.
> +	 * TBD: looking into adding any logs this offline CPU might have,
> +	 * to be collected and reported by the rendezvous master.
> +	 */
> +	if (cpu_is_offline(cpu) && (m.mcgstatus & MCG_STATUS_RIPV))
> +		goto out;

This CPU - it being offline and all - is not doing the minimal amount of
work possible IMO.

Why does it have to do ist_enter(), this_cpu_inc(mce_exception_count),
etc?

IMO the only things it should do is this:

	if (cpu_is_offline(smp_processor_id())) {
		mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
		return;
	}

and that should be at the very beginning of do_machine_check(). So
that the hardware is happy. Concerning Linux, it is offline so no data
structures on it are valid.

Hmmm?

P.S., please don't put stable@ to CC - add it as a "CC: " line in the
SOB section instead.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283977 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

Hi Boris

On Fri, Dec 04, 2015 at 03:34:04PM +0100, Borislav Petkov wrote:
> > @@ -1008,6 +1009,14 @@ void do_machine_check(struct pt_regs *regs, long error_code)
> > +	if (cpu_is_offline(cpu) && (m.mcgstatus & MCG_STATUS_RIPV))
> > +		goto out;
> 
> This CPU - it being offline and all - is not doing the minimal amount of
> work possible IMO.
> 
> Why does it have to do ist_enter(), this_cpu_inc(mce_exception_count),
> etc?

Yes, thats possible to not do ist_enter() and the exception count. 

I tried to keep most of the part as is and leveraging code already
doing the reading of MCG_STATUS. Architecturally we need to also check RIPV
and if clear we should initiate shutdown. 

When we add the logging from offline cpus as next step it would be safe to 
use interrupt stack, and the offline 

I liked the observability part keeping the exception count. if and when we 
online the cpu again, it might look as it noticed nothing. Now we can 
check /proc/interrupts and see the offline cpu also observed the MCE.
> 
> IMO the only things it should do is this:
> 
> 	if (cpu_is_offline(smp_processor_id())) {
> 		mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
> 		return;
> 	}
> 
> and that should be at the very beginning of do_machine_check(). So
> that the hardware is happy. Concerning Linux, it is offline so no data
> structures on it are valid.

> 
> P.S., please don't put stable@ to CC - add it as a "CC: " line in the
> SOB section instead.

Let me know what you think, i can resend with the Cc: stable line.. I 
Did add the stable line in the right section in an earlier version, but 
deleting some extraneous commit messages accidently got to this one :(. 

Cheers,
Ashok

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284025 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Fri, Dec 04, 2015 at 12:14:20PM -0500, Raj, Ashok wrote:
> Yes, thats possible to not do ist_enter() and the exception count. 
> 
> I tried to keep most of the part as is and leveraging code already
> doing the reading of MCG_STATUS. Architecturally we need to also check RIPV
> and if clear we should initiate shutdown.

So add that check too.

> When we add the logging from offline cpus as next step it would be safe to 
> use interrupt stack, and the offline

Franky, I'm not sure at all and very very wary of adding *any* code
which runs on an offlined CPU. Because *no one* does that and it hasn't
been tested at all. So who knows what happens.

What we should be doing is execute the *minimal* amount of code possible
and get out. No counting, no per-cpu variables. No nothing.

> I liked the observability part keeping the exception count. if and
> when we online the cpu again, it might look as it noticed nothing. Now
> we can check /proc/interrupts and see the offline cpu also observed
> the MCE.

And? Tell us what? That SMM fondled the hardware under our feet. TBH,
I'd tend to be much more drastic here and even taint the kernel. I mean,
seriously, what kind of MCEs which happen as a result of OS execution
are you expecting to get reported on an offlined CPU?

I can't think of very any.

Because we have been considering offlining a core as one possible RAS
action. So what happens is a user or a RAS agent offlines a core and
yet, that offlined core still reports MCEs. Something's terribly wrong
with that picture, IMO.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284075 — RE: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

PiBGcmFua3ksIEknbSBub3Qgc3VyZSBhdCBhbGwgYW5kIHZlcnkgdmVyeSB3YXJ5IG9mIGFkZGlu
ZyAqYW55KiBjb2RlDQo+IHdoaWNoIHJ1bnMgb24gYW4gb2ZmbGluZWQgQ1BVLiBCZWNhdXNlICpu
byBvbmUqIGRvZXMgdGhhdCBhbmQgaXQgaGFzbid0DQo+IGJlZW4gdGVzdGVkIGF0IGFsbC4gU28g
d2hvIGtub3dzIHdoYXQgaGFwcGVucy4NCj4NCj4gV2hhdCB3ZSBzaG91bGQgYmUgZG9pbmcgaXMg
ZXhlY3V0ZSB0aGUgKm1pbmltYWwqIGFtb3VudCBvZiBjb2RlIHBvc3NpYmxlDQo+IGFuZCBnZXQg
b3V0LiBObyBjb3VudGluZywgbm8gcGVyLWNwdSB2YXJpYWJsZXMuIE5vIG5vdGhpbmcuDQoNClRo
ZSBtaW5pbWFsIGNvZGUgcmVxdWlyZXMgd2UgdXNlOg0KDQogICAgc21wX3Byb2Nlc3Nvcl9pZCgp
IFt0byBnZXQgb3VyIGNwdSBudW1iZXJdDQogICAgY3B1X2lzX29mZmxpbmUoKSBbdG8gZmluZCBv
dXQgdGhlIGNwdSBpcyBvZmZsaW5lXQ0KDQpUaGUgZmlyc3Qgb2YgdGhvc2UgbG9va3MgbW9yZSBk
YW5nZXJvdXMgaW4gdGhhdCBpdCBhY2Nlc3NlcyBhIHBlci1jcHUgdmFyaWFibGUuDQoNCkkgZG9u
J3QgdGhpbmsgd2UgbmVlZCB0byBiZSB0b3RhbGx5IHBhcmFub2lkIGhlcmUuICBXZSBrbm93IHRo
YXQgdGhlIG9mZmxpbmUgY3B1cw0Kd2VyZSBvbmNlIG9ubGluZSBhbmQgd2VudCB0aHJvdWdoIG5v
cm1hbCBrZXJuZWwgaW5pdGlhbGl6YXRpb24gY29kZSAoaWYgdGhleSBkaWRuJ3QsDQp0aGVuIHdl
IGNhbid0IHBvc3NpYmx5IGJlIGV4ZWN1dGluZyB0aGlzIGNvZGUgLi4uIHRoZWlyIENSNC5NQ0Ug
Yml0IHdvdWxkIGJlIHplcm8gc28gdGhlaXINCnJlc3BvbnNlIHRvIGEgbWFjaGluZSBjaGVjayB3
b3VsZCBoYXZlIGJlZW4gdG8gcmVzZXQgdGhlIHN5c3RlbSkuDQoNCj4gQmVjYXVzZSB3ZSBoYXZl
IGJlZW4gY29uc2lkZXJpbmcgb2ZmbGluaW5nIGEgY29yZSBhcyBvbmUgcG9zc2libGUgUkFTDQo+
IGFjdGlvbi4gU28gd2hhdCBoYXBwZW5zIGlzIGEgdXNlciBvciBhIFJBUyBhZ2VudCBvZmZsaW5l
cyBhIGNvcmUgYW5kDQo+IHlldCwgdGhhdCBvZmZsaW5lZCBjb3JlIHN0aWxsIHJlcG9ydHMgTUNF
cy4gU29tZXRoaW5nJ3MgdGVycmlibHkgd3JvbmcNCj4gd2l0aCB0aGF0IHBpY3R1cmUsIElNTy4N
Cg0KQWdyZWVkLiBJdCB3b3VsZCBiZSBtb3JlIHBsZWFzYW50IGlmIHdlIGhhZCBzb21lIHdheSB0
byAqcmVhbGx5KiBvZmZsaW5lIGEgY3B1LA0KaW5jbHVkaW5nIHRlbGxpbmcgdGhlIHJlc3Qgb2Yg
dGhlIHN5c3RlbSBub3QgdG8gc2VuZCBpdCBhbnkgbW9yZSBicm9hZGNhc3QgZXZlbnRzDQpsaWtl
IE1DRSwgU01JLiAgQnV0IHRoZSBoL3cgZ3V5cyBsaWtlIHRvIGdpdmUgdGhlIHMvdyBndXlzIGpv
YiBzZWN1cml0eSBieSBtYWtpbmcNCnRoZXNlIGNvcm5lciBjYXNlcyB0aGF0IHdlIGhhdmUgdG8g
d29yayBhcm91bmQgaW4gcy93IDotKQ0KDQotVG9ueQ0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284090 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Fri, Dec 04, 2015 at 05:23:18PM +0000, Luck, Tony wrote:
> > Franky, I'm not sure at all and very very wary of adding *any* code
> > which runs on an offlined CPU. Because *no one* does that and it hasn't
> > been tested at all. So who knows what happens.
> >
> > What we should be doing is execute the *minimal* amount of code possible
> > and get out. No counting, no per-cpu variables. No nothing.
> 
> The minimal code requires we use:
> 
>     smp_processor_id() [to get our cpu number]
>     cpu_is_offline() [to find out the cpu is offline]
> 
> The first of those looks more dangerous in that it accesses a per-cpu variable.
> 
> I don't think we need to be totally paranoid here.  We know that the offline cpus
> were once online and went through normal kernel initialization code (if they didn't,
> then we can't possibly be executing this code ... their CR4.MCE bit would be zero so their
> response to a machine check would have been to reset the system).

I don't mean that - I mean the stuff we do before we call
cpu_is_offline() like ist_enter, this_cpu_inc(mce_exception_count),
etc. Then we do a whole another bunch of stuff at the "out:" label like
printk and whatnot which shouldn't run on an offlined CPU.

I.e., the check whether a CPU is offline should be the first thing we do
in do_machine_check and get the hell out if so.

> Agreed. It would be more pleasant if we had some way to *really* offline a cpu,
> including telling the rest of the system not to send it any more broadcast events
> like MCE, SMI.  But the h/w guys like to give the s/w guys job security by making
> these corner cases that we have to work around in s/w :-)

Mind you, this is unintentional from the hw guys. But ha(!), I know
*exactly* what you mean.

:-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284123 — RE: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

PiBJIGRvbid0IG1lYW4gdGhhdCAtIEkgbWVhbiB0aGUgc3R1ZmYgd2UgZG8gYmVmb3JlIHdlIGNh
bGwNCj4gY3B1X2lzX29mZmxpbmUoKSBsaWtlIGlzdF9lbnRlciwgdGhpc19jcHVfaW5jKG1jZV9l
eGNlcHRpb25fY291bnQpLA0KPiBldGMuIFRoZW4gd2UgZG8gYSB3aG9sZSBhbm90aGVyIGJ1bmNo
IG9mIHN0dWZmIGF0IHRoZSAib3V0OiIgbGFiZWwgbGlrZQ0KPiBwcmludGsgYW5kIHdoYXRub3Qg
d2hpY2ggc2hvdWxkbid0IHJ1biBvbiBhbiBvZmZsaW5lZCBDUFUuDQoNCmlzdF9lbnRlcigpIGlz
IGJsYWNrIG1hZ2ljIHRvIG1lLiBBbmR5PyBXb3VsZCB5b3UgYmUgd29ycmllZCBhYm91dCBleGVj
dXRpbmcNCmlzdF97ZW50ZXIsZXhpdH0oKSBvbiBhIGNwdSB0aGF0IHdhcyBvbmNlIG9ubGluZSwg
YnV0IGlzIGN1cnJlbnRseSBtYXJrZWQgb2ZmbGluZQ0KYnkgTGludXg/DQoNCkJ1bXBpbmcgbWNl
X2V4Y2VwdGlvbl9jb3VudCBkb2Vzbid0IGxvb2sgbGlrZSBhIGJpZyBkZWFsIGVpdGhlciB3YXku
IEl0IGlzIHZpc2libGUgaW4NCi9wcm9jL2ludGVycnVwdHMgc28gSSdkIGxpa2UgdG8ga2VlcCB0
aGF0IGhvbmVzdCAoaWYgdGhlIGNwdSBjb21lcyBiYWNrIG9ubGluZSBhZ2FpbikuDQpCdXQgd2Ug
Y291bGQgZG8gdGhlIG9mZmxpbmUgY2hlY2sgYmVmb3JlIHRoaXMuDQoNClRoZXJlIHdpbGwgYmUg
bm8gcHJpbnRrKCkgZXhlY3V0ZWQgaW4gdGhlIHRhaWwgb2YgdGhlIGZ1bmN0aW9uLiBhZnRlciB3
ZSBjbGVhciBNQ0dfU1RBVFVTDQphdCB0aGUgKG5ldyBsb2NhdGlvbiBvZikgdGhlIG91dDogbGFi
ZWwgd2Ugd2lsbCBzZWUgcmVjb3Zlcl9wYWRkciBpcyBzdGlsbCB+MHVsbCBhbmQgImdvdG8gZG9u
ZSIuDQoNCi1Ub255DQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284129 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Fri, Dec 04, 2015 at 05:53:33PM +0000, Luck, Tony wrote:
> > I don't mean that - I mean the stuff we do before we call
> > cpu_is_offline() like ist_enter, this_cpu_inc(mce_exception_count),
> > etc. Then we do a whole another bunch of stuff at the "out:" label like
> > printk and whatnot which shouldn't run on an offlined CPU.
> 
> ist_enter() is black magic to me. Andy? Would you be worried about executing
> ist_{enter,exit}() on a cpu that was once online, but is currently marked offline
> by Linux?

ist_enter() is context tracking functionality.

> Bumping mce_exception_count doesn't look like a big deal either way. It is visible in
> /proc/interrupts so I'd like to keep that honest (if the cpu comes back online again).
> But we could do the offline check before this.
> 
> There will be no printk() executed in the tail of the function. after we clear MCG_STATUS
> at the (new location of) the out: label we will see recover_paddr is still ~0ull and "goto done".

Whether it is kosher or not is beside the point. Why should an offlined
CPU even noodle through all that code if it doesn't need/have to? It can
return immediately instead.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284149 — RE: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

PiBXaGV0aGVyIGl0IGlzIGtvc2hlciBvciBub3QgaXMgYmVzaWRlIHRoZSBwb2ludC4gV2h5IHNo
b3VsZCBhbiBvZmZsaW5lZA0KPiBDUFUgZXZlbiBub29kbGUgdGhyb3VnaCBhbGwgdGhhdCBjb2Rl
IGlmIGl0IGRvZXNuJ3QgbmVlZC9oYXZlIHRvPyBJdCBjYW4NCj4gcmV0dXJuIGltbWVkaWF0ZWx5
IGluc3RlYWQuDQoNCkFzaG9rIHdhbnRzIHRvIG1vdmUgaW4gc3RhZ2UgMiB0byBoYXZpbmcgdGhl
IG9mZmxpbmUgY3B1IHNjYW4gYmFua3MgYW5kIHJlcG9ydA0KYW55IGVycm9ycyBzZWVuIHRoZXJl
LiAgVG8gZG8gdGhhdCB3ZSdsbCBoYXZlIHRvIHJ1biB0aHJvdWdoIGEgZmFpciBiaXQgb2YgdGhl
DQpkb19tYWNoaW5lX2NoZWNrKCkgY29kZS4NCg0KQnV0IC4uLiBpZiB5b3Ugd2FudCBhIHN1cGVy
IHNhZmUgdmVyc2lvbiB0byBwdXQgdGhlIHN0YWJsZSB0YWcgb24gLi4uIHdlIGNvdWxkDQpqdXN0
IGhhdmUgc29tZXRoaW5nIGxpa2UgdGhpcyBhdCB0aGUgaGVhZCBvZiBkb19tYWNoaW5lX2NoZWNr
KCkNCg0KCWludCBjcHUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7DQoNCglpZiAoY3B1X2lzX29mZmxp
bmUoY3B1KSkgew0KCQlyZG1zcihNQ0dfU1RBVFVTKTsNCgkJaWYgKFJJUFYgYml0IHNldCkgew0K
CQkJd3Jtc3IoTUNHX1NUQVRVUywgMCk7DQoJCQlyZXR1cm47DQoJCX0NCgkJLy8gY2FuIHdlIGRv
IGFueXRoaW5nIGhlcmU/IE9mZmxpbmUgY3B1IGhhcyBubyBwbGFjZSB0byByZXR1cm4gdG8uDQoJ
CS8vIFRoZXJlIGFyZSBubyBnb29kIGFuc3dlcnMgLi4uIGZhbGxpbmcgaW50byB0aGUgcmVndWxh
ciBjb2RlIGlzDQoJCS8vIHdoYXQgd2UgZGlkIGhpc3RvcmljYWxseQ0KCX0NCg0KLVRvbnkNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284177 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Fri, Dec 04, 2015 at 06:30:39PM +0000, Luck, Tony wrote:
> Ashok wants to move in stage 2 to having the offline cpu scan banks and report
> any errors seen there.  To do that we'll have to run through a fair bit of the
> do_machine_check() code.

I'm still very sceptical whether logging those errors are worth the risk
of running code on an offlined CPU.

> But ... if you want a super safe version to put the stable tag on ... we could
> just have something like this at the head of do_machine_check()

It would be prudent IMO. We don't want to disrupt stable kernels
unnecessarily.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284307 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Fri, Dec 4, 2015 at 9:53 AM, Luck, Tony <tony.luck@intel.com> wrote:
>> I don't mean that - I mean the stuff we do before we call
>> cpu_is_offline() like ist_enter, this_cpu_inc(mce_exception_count),
>> etc. Then we do a whole another bunch of stuff at the "out:" label like
>> printk and whatnot which shouldn't run on an offlined CPU.
>
> ist_enter() is black magic to me. Andy? Would you be worried about executing
> ist_{enter,exit}() on a cpu that was once online, but is currently marked offline
> by Linux?

Offline CPUs are black magic to me.  But as long as the CPU works the
way that the normal specs say it should, then ist_enter is fair game.
In any event, if context tracking blows up on an offline CPU, I'd
argue that's a context tracking bug and needs to be fixed.

But maybe offlined CPUs are supposed to have all interrupts off
(including MCE?) and the argument goes the other way?  Dunno.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284321 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Fri, Dec 04, 2015 at 02:34:52PM -0800, Andy Lutomirski wrote:
> On Fri, Dec 4, 2015 at 9:53 AM, Luck, Tony <tony.luck@intel.com> wrote:
> > ist_enter() is black magic to me. Andy? Would you be worried about executing
> > ist_{enter,exit}() on a cpu that was once online, but is currently marked offline
> > by Linux?
> 
> Offline CPUs are black magic to me.  But as long as the CPU works the
> way that the normal specs say it should, then ist_enter is fair game.
> In any event, if context tracking blows up on an offline CPU, I'd
> argue that's a context tracking bug and needs to be fixed.
> 
> But maybe offlined CPUs are supposed to have all interrupts off
> (including MCE?) and the argument goes the other way?  Dunno.

MCE's are broadcast by the hardware and cannot be blocked. Offline
is only a Linux specific state. Now if the offline was a result of an ACPI
event (eject) that triggered the CPU removal (offline in Linux, as it would 
have in a platform that supports true hotplug) then the platform would 
remove this cpu from the broadcast list. 

if kernel were to set CR4.MCE=0 that would cause system shutdown when 
an MCE is broadcast and hits this cpu.

Cheers,
Ashok
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284330 — Re: [Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

On Fri, Dec 4, 2015 at 4:08 PM, Raj, Ashok <ashok.raj@intel.com> wrote:
> On Fri, Dec 04, 2015 at 02:34:52PM -0800, Andy Lutomirski wrote:
>> On Fri, Dec 4, 2015 at 9:53 AM, Luck, Tony <tony.luck@intel.com> wrote:
>> > ist_enter() is black magic to me. Andy? Would you be worried about executing
>> > ist_{enter,exit}() on a cpu that was once online, but is currently marked offline
>> > by Linux?
>>
>> Offline CPUs are black magic to me.  But as long as the CPU works the
>> way that the normal specs say it should, then ist_enter is fair game.
>> In any event, if context tracking blows up on an offline CPU, I'd
>> argue that's a context tracking bug and needs to be fixed.
>>
>> But maybe offlined CPUs are supposed to have all interrupts off
>> (including MCE?) and the argument goes the other way?  Dunno.
>
> MCE's are broadcast by the hardware and cannot be blocked. Offline
> is only a Linux specific state. Now if the offline was a result of an ACPI
> event (eject) that triggered the CPU removal (offline in Linux, as it would
> have in a platform that supports true hotplug) then the platform would
> remove this cpu from the broadcast list.
>
> if kernel were to set CR4.MCE=0 that would cause system shutdown when
> an MCE is broadcast and hits this cpu.

I meant "supposed" as in Linux might expect arch code to prevent the
CPU from receiving interrupts.

Anyway, I think that would be silly and we should just expect
ist_enter to work regardless of online state.

This does mean that if we plug in a new CPU and online it, then
there's a window before we set up percpu memory and enable CR4.MCE in
which an MCE on any CPU will kill the system, at least on hardware for
which MCE broadcast can't be turned off.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web