linux-kernel - RE: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

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:   Sun, 22 Jan 2017 18:39:28 +0000
From:   Matthew Wilcox <mawilcox@...rosoft.com>
To:     Christoph Hellwig <hch@....de>
CC:     Dan Williams <dan.j.williams@...el.com>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        Brian Boylston <brian.boylston@....com>,
        "Tony Luck" <tony.luck@...el.com>, Jan Kara <jack@...e.cz>,
        Toshi Kani <toshi.kani@....com>,
        Mike Snitzer <snitzer@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>, Jeff Moyer <jmoyer@...hat.com>,
        Jens Axboe <axboe@...com>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "H. Peter Anvin" <hpa@...or.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>
Subject: RE: [PATCH 00/13] dax, pmem: move cpu cache maintenance to     libnvdimm

From: Christoph Hellwig [mailto:hch@....de]
> On Sun, Jan 22, 2017 at 06:19:24PM +0000, Matthew Wilcox wrote:
> > No, I mean a network filesystem like 9p or cifs or nfs.  If the memcpy
> > is supposed to be performed by the backing device
> 
> struct backing_dev has no relation to the DAX code.  Even more so what's
> the point of doing a DAXish memcpy in that case?  If we buffer in
> memory for network I/O we should just use the page cache.

Oh, I didn't mean a 'struct backing_dev'.  I meant that, conceptually, there is no driver for the filesystem to call.  Here's the architecture that I'm trying to work with:

Two guests on the same physical machine (or a guest and a host) have access to the same set of physical addresses.  This might be an NV-DIMM, or it might just be DRAM (for the purposes of reducing guest overhead).  The network filesystem has been enhanced with a call to allow the client to ask the server "What is the physical address for this range of bytes in this file?"

We don't want to use the guest pagecache here.  That's antithetical to the second usage, and it's inefficient for the first usage.