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
| ||
|
Date: Tue, 17 Feb 2015 10:42:26 +0200 From: Boaz Harrosh <boaz@...xistor.com> To: Matthew Wilcox <willy@...ux.intel.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 02/17/2015 12:03 AM, Matthew Wilcox wrote: > 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. > I had a feeling I'm entering an holy war ;-). I hope you are OK with my first patch. That an unknown type need not be reported busy, and behave same as "reserved"? Then if we agree about PATCH-1, which is the actual fix. Then the 2nd patch (hence the RFC btw) is nothing more than a name. I have an old BIOS that knows nothing of NvDIMM, actually a few of them they all report 12. The fact of the matter is that all the people I've talked with, reported that different vendor chips, all came up type-12. Perhaps type-12 just means "Unknown to current BIOS" What is the name you suggest "type-12" "unknown-12". Do you understand why they all come out 12 ? Thanks Boaz -- 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/
Powered by blists - more mailing lists