linux-kernel - Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

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.20.1704122259490.2548@nanos>
Date:   Wed, 12 Apr 2017 23:12:21 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dan Williams <dan.j.williams@...el.com>
cc:     "Luck, Tony" <tony.luck@...el.com>,
        "Verma, Vishal L" <vishal.l.verma@...el.com>,
        "bp@...e.de" <bp@...e.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
        "ross.zwisler@...ux.intel.com" <ross.zwisler@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from
 'atomic'


On Wed, 12 Apr 2017, Dan Williams wrote:

> On Wed, Apr 12, 2017 at 1:52 PM, Luck, Tony <tony.luck@...el.com> wrote:
> > On Wed, Apr 12, 2017 at 01:27:05PM -0700, Verma, Vishal L wrote:
> >> >     /* We only care about memory errors */
> >> >     if (!(mce->status & MCACOD))
> >> >             return NOTIFY_DONE;
> >
> > N.B. that isn't a valid test that this is a memory error. You need
> >
> >
> >         if (!(m->status & 0xef80) == BIT(7))
> >                 return NOTIFY_DONE;
> >
> > See: Intel SDM Volume 3B - 15.9.2 Compound Error Codes
> 
> But Vishal's point is that even if we get this check correct the
> notifier still requires no sleeping operations. So we would need to
> move recoverable notifications to a separate blocking notifier chain.

There is another solution:

Convert the notifier to a blocking notifier and in the panic case, ignore
the locking and invoke the notifier chain directly. That needs some minimal
surgery in the notifier code to allow that, but that's certainly less ugly
than splitting stuff up into two chains.

Thanks,

	tglx