linux-kernel - Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX documentation

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: <20160122143900.GE2948@linux.intel.com>
Date:	Fri, 22 Jan 2016 09:39:00 -0500
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Chris Brandt <Chris.Brandt@...esas.com>
Cc:	"Wilcox, Matthew R" <matthew.r.wilcox@...el.com>,
	Jared Hulbert <jaredeh@...il.com>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Carsten Otte <cotte@...ibm.com>
Subject: Re: [PATCH v12 10/20] dax: Replace XIP documentation with DAX
 documentation

On Fri, Jan 22, 2016 at 01:48:08PM +0000, Chris Brandt wrote:
> I believe the motivation for the new DAX code was being able to
> read/write data directly to specific physical memory. However, with
> the AXFS file system, XIP file mapping was mostly beneficial for direct
> access to executable code pages, not data. Code pages were XIP-ed, and
> data pages were copied to RAM as normal. This results in a significant
> reduction in system RAM, especially when used with an XIP_KERNEL. In
> some systems, most of your RAM is eaten up by lots of code pages from
> big bloated shared libraries, not R/W data. (of course I'm talking about
> smaller embedded system here)

OK, I can't construct a failure case for read-only usages.  If you want
to put together a patch-set that re-enables DAX in a read-only way on
those architectures, I'm fine with that.

I think your time would be better spent fixing the read-write problems;
once we see persistent memory on the embedded platforms, we'll need that
code anyway.