linux-kernel - Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips

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: <20150216220302.GF3364@wil.cx>
Date:	Mon, 16 Feb 2015 17:03:02 -0500
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Boaz Harrosh <boaz@...xistor.com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>, x86@...nel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Roger C. Pao" <rcpao.enmotus@...il.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-nvdimm <linux-nvdimm@...ts.01.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips

On Mon, Feb 16, 2015 at 01:07:07PM +0200, Boaz Harrosh wrote:
> In any way this is a problem for the new type-12 NvDIMM memory chips that
> are circulating around. (It is estimated that there are already 100ds of
> thousands NvDIMM chips in active use)

Hang on.  NV-DIMM chips don't know anyhing about E820 tables.  They don't
have anything in them that says "I am type 12!".  How they are reported
is up to the BIOS.  Just because your BIOS vendor has chosen to report
tham as type 12 doesn't mean that any other BIOS vedor is going to have
done the same thing.

Fortunately, the BIOS people have all got together and decided what
they're going to do, and it's not type 12.  Unfortunately, I think
I'm bound by various agreements to not say what they are going to do
until they do.  But putting this temporary workaround in the kernel to
accomodate one BIOS vendor's unreleased experimental code seems like
entirely the wrong idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/