linux-kernel - Re: "Directly mapped persistent memory page cache"

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]

Date:	Mon, 11 May 2015 12:38:02 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"Zuckerman, Boris" <borisz@...com>
Cc:	Dave Chinner <david@...morbit.com>, Rik van Riel <riel@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	John Stoffel <john@...ffel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Boaz Harrosh <boaz@...xistor.com>, Jan Kara <jack@...e.cz>,
	Mike Snitzer <snitzer@...hat.com>, Neil Brown <neilb@...e.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Chris Mason <clm@...com>, Paul Mackerras <paulus@...ba.org>,
	"H. Peter Anvin" <hpa@...or.com>, Christoph Hellwig <hch@....de>,
	Alasdair Kergon <agk@...hat.com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
	Mel Gorman <mgorman@...e.de>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Jens Axboe <axboe@...nel.dk>, Theodore Ts'o <tytso@....edu>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Julia Lawall <Julia.Lawall@...6.fr>, Tejun Heo <tj@...nel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: "Directly mapped persistent memory page cache"

* Zuckerman, Boris <borisz@...com> wrote:

> Hi,
> 
> Data transformation (EC, encryption, etc) is commonly done by 
> storage systems today. [...]

That's a strawman argument: if you do encryption/compression in the 
storage space then you don't need complex struct page descriptors for 
the storage space: as the resulting content won't be mappable nor 
DMA-able into from high level APIs...

My proposal adds a RAM-integrated usage model for devices that are 
directly mapped in physical RAM space (such as persistent memory), 
where integration with high level Linux APIs is possible and 
desirable.

If pmem is used as a front-side cache for a larger storage system 
behind, then the disk side can still be encrypted/compressed/etc.

( Also note that if the pmem hardware itself adds an encryption pass 
  then actual stored content might still be encrypted. )

> [...] But let's think about other less common existing and PM 
> specific upcoming features like data sharing between multiple 
> consumers (computers for example), [...]

RDMA should work fine if the pmem hardware exposes it.

> [...] support for atomicity (to avoid journaling in PM space), etc.

This too should work fine, by way of the SMP coherency protocol, if 
atomic instructions are used on the relevant metadata.

Thanks,

	Ingo
--
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/