linux-kernel - Re: [PATCH v7 00/22] Support ext4 on NV-DIMMs

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: <20140617181925.GF12025@linux.intel.com>
Date:	Tue, 17 Jun 2014 14:19:25 -0400
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Boaz Harrosh <openosd@...il.com>
Cc:	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 00/22] Support ext4 on NV-DIMMs

On Tue, Jun 17, 2014 at 09:11:47PM +0300, Boaz Harrosh wrote:
> Looking at the brd code I fail to see how it will ever support NV_DIMMS.
> brd is "struct page" based and shares RAM from the same memory pool as the rest
> of the system. But NV_DIMMS is not page-based and is excluded from the
> memory system. It needs to be exclusively owned by a device and the mounted
> FS.
> 
> We currently have in our lab the old DDR3 based NV_DIMMS and on regular boot
> it appears as RAM. We need to use memmap= option on command line of Kernel
> to exclude it from use by Kernel.
> 
> We have received our DDR4 based NV_DIMMS but still waiting for the actual
> system board to support it. As I understand from STD documentation
> these devices will not identify as RAM and will be exported as ACPI or
> SBUS devices that can be queried for sizes and address as well as properties
> about the chips. So I imagine a udev rule will need to probe the right driver
> to mount over those.
> 
> So currently from what I can see only the infamous PMFS is the setup that
> can actually mount/support my NV_DIMMS today.
> 
> It seems to me like we need a *new* block device that receives, like PMFS,
> an physical_address + size on load and will export this raw region as a block
> device. Of course with support of new DAX API. Should I send in such a device
> code.
> 
> (I've seen the linux-nvdimm project on github but did not see how my above
>  problem is addressed, it looks geared for that other type DDR bus devices)
> 
> So please how is all that suppose to work, what is the strategy stack
> for all this? I guess for now I'm stuck with PMFS.
> 
> (BTW: A public git tree of DAX patches ;-) )

https://github.com/01org/prd should sort you out with both a git tree
and a new block driver.  You'll need to tell it manually what address
range to use.  I'm using it against regular DIMMs, and this works pretty
well for me since my BIOS doesn't zero DRAM on reset.
--
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/