linux-kernel - Re: [PATCH 3/3] x86/mce: Check for alternate indication of machine check recovery on Skylake

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1806072223270.1591@nanos.tec.linutronix.de>
Date:   Thu, 7 Jun 2018 22:24:56 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dan Williams <dan.j.williams@...el.com>
cc:     "Luck, Tony" <tony.luck@...el.com>, Borislav Petkov <bp@...e.de>,
        Qiuxu Zhuo <qiuxu.zhuo@...el.com>,
        Ashok Raj <ashok.raj@...el.com>, X86 ML <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] x86/mce: Check for alternate indication of machine
 check recovery on Skylake


On Thu, 7 Jun 2018, Dan Williams wrote:

> On Thu, Jun 7, 2018 at 10:43 AM, Luck, Tony <tony.luck@...el.com> wrote:
> > On Fri, May 25, 2018 at 02:42:09PM -0700, Tony Luck wrote:
> >> Currently we just check the "CAPID0" register to see whether the CPU
> >> can recover from machine checks.
> >>
> >> But there are also some special SKUs which do not have all advanced
> >> RAS features, but do enable machine check recovery for use with NVDIMMs.
> >>
> >> Add a check for any of bits {8:5} in the "CAPID5" register (each
> >> reports some NVDIMM mode available, if any of them are set, then
> >> the system supports memory machine check recovery).
> >>
> >> Cc: stable@...r.kernel.org # 4.9
> >> Signed-off-by: Tony Luck <tony.luck@...el.com>
> >> ---
> >
> > Has this stalled somewhere?  I'd like to see this one go into the
> > 4.18 merge because it unbreaks some real hardware.
> >
> > Parts 1 & 2 are nice-to-have, but they just make for better error
> > messages so aren't as critical.
> 
> I'm making an effort to get all persistent memory error handling holes
> covered this cycle, so I think it makes sense for this to go through
> the nvdimm tree. This looks sufficiently non-controversial that I
> could justify sending it to Linus along with the other pmem updates.

I've picked it up already and please can we let stuff go through the right
trees? The worlds does not stop turning if a fix goes in 2 days later.

Thanks,

	tglx