linux-kernel - Re: [Linux-nvdimm] another pmem variant

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: <CAPcyv4gaGQ-4bYp2djHnLGLLCr9gD8pZP2Lb1ACNP8G4fSzd=w@mail.gmail.com>
Date:	Wed, 25 Mar 2015 09:33:52 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Christoph Hellwig <hch@....de>
Cc:	linux-nvdimm <linux-nvdimm@...1.01.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Jens Axboe <axboe@...nel.dk>
Subject: Re: [Linux-nvdimm] another pmem variant

On Wed, Mar 25, 2015 at 9:04 AM, Christoph Hellwig <hch@....de> wrote:
> Here is another version of the same trivial pmem driver, because two
> obviously aren't enough.

Welcome to the party! :-)

> The first patch is the same pmem driver
> that Ross posted a short time ago, just modified to use platform_devices
> to find the persistant memory region instead of hardconding it in the
> Kconfig.  This allows to keep pmem.c separate from any discovery mechanism,
> but still allow auto-discovery.

This is mostly ok and does not collide too much with the upcoming ACPI
mechanism for this stuff.  I do worry that the new
"memmap=nn[KMG]!ss[KMG]" kernel command line option will only be
relevant for at most one kernel cycle given the imminent publication
of the spec that unblocks our release.

Our planned solution to the "legacy pmem" problem is to have a
userspace utility craft a list of address ranges in the form that ACPI
expects and attach that to a platform device (one time setup).  It
only requires that the memory be marked reserved, not necessarily
marked type-12.

> The other two patches are a heavily rewritten version of the code that
> Intel gave to various storage vendors to discover the type 12 (and earlier
> type 6) nvdimms, which I massaged into a form that is hopefully suitable
> for mainline.

I'd prefer E820_PMEM over E820_PROTECTED_KERN, I don't know why I
chose that name initially, but to each his own bike shed.
--
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/