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

Groups > linux.kernel > #1274742 > unrolled thread

Re: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors into the genpool.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors  into the genpool. Borislav Petkov <bp@alien8.de> - 2015-11-21 20:20 +0100
    RE: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred  errors into the genpool. "Luck, Tony" <tony.luck@intel.com> - 2015-11-24 01:20 +0100
      Re: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors  into the genpool. Borislav Petkov <bp@alien8.de> - 2015-11-24 08:40 +0100
        RE: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred  errors into the genpool. "Luck, Tony" <tony.luck@intel.com> - 2015-11-24 17:00 +0100
          Re: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors  into the genpool. Borislav Petkov <bp@alien8.de> - 2015-11-24 20:00 +0100

#1274742 — Re: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors into the genpool.

On Wed, Nov 11, 2015 at 02:01:51PM -0800, Tony Luck wrote:
> We used to have a special ring buffer for deferred errors that
> was used to mark problem pages. We replaced that with a genpool.
> Then later converted mce_log() to also use the same genpool. As
> a result we end up adding all deferred errors to the genpool twice.
> 
> Rearrange this code. Make sure to set the m.severity and m.usable_addr
> fields for deferred errors. Then if flags and mca_cfg.dont_log_ce mean
> we call mce_log() we are done, because that will add this entry to the
> genpool.
> 
> If we skipped mce_log(), then we still want to take action for the
> deferred error, so add to the genpool.
> 
> Changed the name of the boolean "error_logged" to "error_seen", we
> should set it whether of not we logged an error because the return
> value from machine_check_poll() is used to decide whether storms
> have subsided or not.
> 
> Reported-by: Chen, Gong <gong.chen.linux.intel.com>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)

...

> @@ -626,9 +621,16 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t *b)
>  		 * Don't get the IP here because it's unlikely to
>  		 * have anything to do with the actual error location.
>  		 */
> -		if (!(flags & MCP_DONTLOG) && !mca_cfg.dont_log_ce) {
> -			error_logged = true;
> +		if (!(flags & MCP_DONTLOG) && !mca_cfg.dont_log_ce)
>  			mce_log(&m);
> +		else if (m.usable_addr) {
> +			/*
> +			 * Although we skipped logging this, we still want
> +			 * to take action. Add to the pool so the registered
> +			 * notifiers will see it.
> +			 */
> +			if (!mce_gen_pool_add(&m))
> +				mce_schedule_work();

Right, this still causes the error to come out on AMD because the
notifier calls amd_decode_mce().

I guess we can extend the "if (m.usable_addr)" check above with "if
error is not CE" too and only add it to the generic pool when its
severity is anything stronger than MCE_KEEP_SEVERITY...

Also, two more fixes I've done while injecting in a kvm guest I'm
sending as a reply to this message. Will inject on a real box too.

Thanks.

-- 
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] | [next] | [standalone]

#1275979 — RE: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors into the genpool.

PiBBbHNvLCB0d28gbW9yZSBmaXhlcyBJJ3ZlIGRvbmUgd2hpbGUgaW5qZWN0aW5nIGluIGEga3Zt
IGd1ZXN0IEknbQ0KPiBzZW5kaW5nIGFzIGEgcmVwbHkgdG8gdGhpcyBtZXNzYWdlLiBXaWxsIGlu
amVjdCBvbiBhIHJlYWwgYm94IHRvby4NCg0KT2sgLi4uIGFwcGxpZWQgdGhvc2UgdHdvIG9uIHRv
cCBvZiBteSAiVU5URVNURUQiIHBhdGNoIGFuZCBpbmplY3RlZCBhbiBlcnJvciB0byBmb3JjZSBh
IFVDTkEgbG9nLg0KDQpFdmVyeXRoaW5nIGxvb2tlZCBvay4gICBKdXN0IG9uZSBjb3B5IG9uIHRo
ZSBjb25zb2xlIGFuZCBpbiAvdmFyL2xvZy9tY2Vsb2cgKGFjdHVhbGx5IGxvZ3MgZnJvbQ0KYmFu
azcgYW5kIGJhbmszIC4uLiBidXQgdGhhdCB3YXMgZXhwZWN0ZWQgZnJvbSB0aGlzIHRlc3QpLg0K
DQpTbyBteSBwYXRjaCBpcyB0ZXN0ZWQsIGFuZCB0YWtlIHRoaXMNCg0KQWNrZWQtYnk6IFRvbnkg
THVjayA8dG9ueS5sdWNrQGludGVsLmNvbT4gZm9yIHlvdXIgdHdvIGFkZGl0aW9uYWwgcGF0Y2hl
cy4NCg0KLVRvbnkNCg==
--
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]

#1276111

On Tue, Nov 24, 2015 at 12:19:18AM +0000, Luck, Tony wrote:
> > Also, two more fixes I've done while injecting in a kvm guest I'm
> > sending as a reply to this message. Will inject on a real box too.
> 
> Ok ... applied those two on top of my "UNTESTED" patch and injected an error to force a UCNA log.

Ok, what error type is that in EINJ nomenclature? I had only

/sys/kernel/debug/apei/einj/available_error_type:0x00000002     Processor Uncorrectable non-fatal
/sys/kernel/debug/apei/einj/available_error_type:0x00000008     Memory Correctable
/sys/kernel/debug/apei/einj/available_error_type:0x00000010     Memory Uncorrectable non-fatal

and I would've guessed it is the 0x10 type, i.e., the memory
uncorrectable which is non-fatal - assuming here - but that one got
promoted to a #MC on my box.

The processor uncorrectable didn't want to inject due to missing EINJ
instruction 0x5 or so...

> Everything looked ok. Just one copy on the console and in
> /var/log/mcelog (actually logs from bank7 and bank3 ... but that was
> expected from this test).

Good.

> So my patch is tested, and take this
> 
> Acked-by: Tony Luck <tony.luck@intel.com> for your two additional patches.

Thanks!

-- 
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]

#1276591 — RE: [UNTESTED PATCH] x86, mce: Avoid double entry of deferred errors into the genpool.

Pj4gT2sgLi4uIGFwcGxpZWQgdGhvc2UgdHdvIG9uIHRvcCBvZiBteSAiVU5URVNURUQiIHBhdGNo
IGFuZCBpbmplY3RlZCBhbiBlcnJvciB0byBmb3JjZSBhIFVDTkEgbG9nLg0KPg0KPiBPaywgd2hh
dCBlcnJvciB0eXBlIGlzIHRoYXQgaW4gRUlOSiBub21lbmNsYXR1cmU/IEkgaGFkIG9ubHkNCj4N
Cj4gL3N5cy9rZXJuZWwvZGVidWcvYXBlaS9laW5qL2F2YWlsYWJsZV9lcnJvcl90eXBlOjB4MDAw
MDAwMDIgICAgIFByb2Nlc3NvciBVbmNvcnJlY3RhYmxlIG5vbi1mYXRhbA0KPiAvc3lzL2tlcm5l
bC9kZWJ1Zy9hcGVpL2VpbmovYXZhaWxhYmxlX2Vycm9yX3R5cGU6MHgwMDAwMDAwOCAgICAgTWVt
b3J5IENvcnJlY3RhYmxlDQo+IC9zeXMva2VybmVsL2RlYnVnL2FwZWkvZWluai9hdmFpbGFibGVf
ZXJyb3JfdHlwZToweDAwMDAwMDEwICAgICBNZW1vcnkgVW5jb3JyZWN0YWJsZSBub24tZmF0YWwN
Cj4NCj4gYW5kIEkgd291bGQndmUgZ3Vlc3NlZCBpdCBpcyB0aGUgMHgxMCB0eXBlLCBpLmUuLCB0
aGUgbWVtb3J5DQo+IHVuY29ycmVjdGFibGUgd2hpY2ggaXMgbm9uLWZhdGFsIC0gYXNzdW1pbmcg
aGVyZSAtIGJ1dCB0aGF0IG9uZSBnb3QNCj4gcHJvbW90ZWQgdG8gYSAjTUMgb24gbXkgYm94Lg0K
DQpJIGp1Z2dsZWQgd2l0aCB0aGUgdHlwZSBvZiB0aGUgaW5qZWN0aW9uIGFuZCB0aGUgaW5zdHJ1
Y3Rpb24gc2VxdWVuY2UgdG8gYWNjZXNzIHRoZSB0YXJnZXQNCmxvY2F0aW9uLiAgSSB1c2VkIDB4
MTAgdG8gaW5qZWN0IGFuIHVuY29ycmVjdGVkIG1lbW9yeSBlcnJvciB3aXRoICIjIGVjaG8gMSA+
IG5vdHJpZ2dlciINCnRvIG1ha2Ugc3VyZSB0aGUgRUlOSiBkcml2ZXIgc2tpcHBlZCB0aGUgdHJp
Z2dlciBhY3Rpb25zLiBUaGVuIEkgaGFkIGEgdXNlciBtb2RlIHRlc3QgcHJvZ3JhbQ0Kd3JpdGUg
YSBieXRlIHRvIHRoZSBjYWNoZSBsaW5lLiAgVGhhdCBwdWxsZWQgdGhlIHVuY29ycmVjdGVkIGRh
dGEgaW50byB0aGUgY2FjaGUgKHdoaWNoIGxvZ2dlZA0KdGhlIFVDTkEgZXJyb3Igc2lnbmFsZWQg
d2l0aCBDTUNJKS4gQnV0IHRoZSBwcm9jZXNzb3IgZGlkbid0IGFjdHVhbGx5IGNvbnN1bWUgdGhl
IHBvaXNvbg0KKG5vIHJlZ2lzdGVycyBoYWQgY29ycnVwdGVkIGRhdGEpLCBzbyB0aGVyZSB3YXMg
bm8gbWFjaGluZSBjaGVjay4NCg0KU25lYWt5LCBodWg/DQoNCi1Ub255DQo=
--
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]

#1276719

On Tue, Nov 24, 2015 at 03:51:21PM +0000, Luck, Tony wrote:
> >> Ok ... applied those two on top of my "UNTESTED" patch and injected an error to force a UCNA log.
> >
> > Ok, what error type is that in EINJ nomenclature? I had only
> >
> > /sys/kernel/debug/apei/einj/available_error_type:0x00000002     Processor Uncorrectable non-fatal
> > /sys/kernel/debug/apei/einj/available_error_type:0x00000008     Memory Correctable
> > /sys/kernel/debug/apei/einj/available_error_type:0x00000010     Memory Uncorrectable non-fatal
> >
> > and I would've guessed it is the 0x10 type, i.e., the memory
> > uncorrectable which is non-fatal - assuming here - but that one got
> > promoted to a #MC on my box.
> 
> I juggled with the type of the injection and the instruction sequence to access the target
> location.  I used 0x10 to inject an uncorrected memory error with "# echo 1 > notrigger"
> to make sure the EINJ driver skipped the trigger actions. Then I had a user mode test program
> write a byte to the cache line.  That pulled the uncorrected data into the cache (which logged
> the UCNA error signaled with CMCI). But the processor didn't actually consume the poison
> (no registers had corrupted data), so there was no machine check.
> 
> Sneaky, huh?

That reminds me of the whitepaper:

https://software.intel.com/sites/default/files/managed/b3/d1/MCA_Recovery_Validation_Guide.pdf

Btw, should we take those tools here:

https://git.kernel.org/cgit/linux/kernel/git/aegl/ras-tools.git

and glue them together with a python or a shell script or so which
goes and automatically takes care of loading einj.ko and injects the
proper error type and thus abstracts away all that detail which makes me
everytime look at Documentation/acpi/apei/einj.txt?

Something like

./einject.py --ucna

which would do all the fun?

That would simplify our testing a lot, methinks. Hmmm?

Oh, and btw, the box here didn't have the notrigger node, which means,
it'll always do the trigger actions. :-\

-- 
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] | [standalone]

Back to top | Article view | linux.kernel

csiph-web