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

Groups > linux.kernel > #1740256 > unrolled thread

Re: [PATCH] x86/MCE/AMD: Always give PANIC severity for UC errors in kernel context

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: [PATCH] x86/MCE/AMD: Always give PANIC severity for UC errors in  kernel context Borislav Petkov <bp@alien8.de> - 2017-09-27 00:30 +0200
    RE: [PATCH] x86/MCE/AMD: Always give PANIC severity for UC errors in  kernel context "Ghannam, Yazen" <Yazen.Ghannam@amd.com> - 2017-09-27 17:20 +0200
      Re: [PATCH] x86/MCE/AMD: Always give PANIC severity for UC errors in  kernel context Borislav Petkov <bp@alien8.de> - 2017-09-27 17:30 +0200

#1740256 — Re: [PATCH] x86/MCE/AMD: Always give PANIC severity for UC errors in kernel context

On Tue, Sep 26, 2017 at 03:21:22PM +0000, Ghannam, Yazen wrote:
> How should I CC:stable?

Documentation/process/stable-kernel-rules.rst

> There are the stable branches on kernel.org and some distro kernels based on
> older kernel versions.
> 
> The AMD severity grading function was introduced in v4.1 and has this issue.
> However, the following commit was included in v4.6 and masks the issue.
> 
> b2f9d678e28c x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries
> 
> This patch will apply to v4.9 and later. Another version will be needed to apply
> to the v4.1 and v4.4. stable branches.

Then write that in the commit message. But *also* add the main reason
why you're doing this - to explicitly state that IN_KERNEL context is
panicked on on AMD. Because if it weren't for it, old kernels should
simply backport b2f9d678e28c and be done with it.

And I still don't understand the IN_KERNEL_RECOV thing you mention in
the commit message. That's Intel-only, what does it have to do with AMD?

Btw, while at it, fix that signature

static int mce_severity_amd_smca(struct mce *m, int err_ctx)

to

static int mce_severity_amd_smca(struct mce *m, enum context err_ctx)

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [next] | [standalone]

#1740828

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Tuesday, September 26, 2017 6:21 PM
> To: Ghannam, Yazen <Yazen.Ghannam@amd.com>
...
> > There are the stable branches on kernel.org and some distro kernels
> > based on older kernel versions.
> >
> > The AMD severity grading function was introduced in v4.1 and has this
> issue.
> > However, the following commit was included in v4.6 and masks the issue.
> >
> > b2f9d678e28c x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT
> > exception table entries
> >
> > This patch will apply to v4.9 and later. Another version will be
> > needed to apply to the v4.1 and v4.4. stable branches.
> 
> Then write that in the commit message. But *also* add the main reason why
> you're doing this - to explicitly state that IN_KERNEL context is panicked on
> on AMD. Because if it weren't for it, old kernels should simply backport
> b2f9d678e28c and be done with it.
> 

Okay , will do.

> And I still don't understand the IN_KERNEL_RECOV thing you mention in the
> commit message. That's Intel-only, what does it have to do with AMD?
> 

Generally, we can use the IN_KERNEL_RECOV context to show that the error
is recoverable versus IN_KERNEL which we can consider unrecoverable.

Specifically, the Intel SER and AMD SUCCOR features represent the same
thing (MCA Recovery). I'll send another patch for enabling recovery on
AMD SUCCOR systems. I want to keep this patch as just a bug fix. 

> Btw, while at it, fix that signature
> 
> static int mce_severity_amd_smca(struct mce *m, int err_ctx)
> 
> to
> 
> static int mce_severity_amd_smca(struct mce *m, enum context err_ctx)
> 

Sure, I'll do this in another patch. I want to keep this as a bug fix to apply to
the stable branches.

Thanks,
Yazen

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

#1740832

On Wed, Sep 27, 2017 at 03:17:51PM +0000, Ghannam, Yazen wrote:
> Generally, we can use the IN_KERNEL_RECOV context to show that the error
> is recoverable versus IN_KERNEL which we can consider unrecoverable.
> 
> Specifically, the Intel SER and AMD SUCCOR features represent the same
> thing (MCA Recovery). I'll send another patch for enabling recovery on
> AMD SUCCOR systems. I want to keep this patch as just a bug fix.

Ok, but then do not mention IN_KERNEL_RECOV here as it only confuses: is
it a recoverable error or is it not? /me scratches head...

> Sure, I'll do this in another patch. I want to keep this as a bug fix
> to apply to the stable branches.

Sure.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web