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]

Message-ID: <BY2PR21MB00368E95CBB533D4C761C882CB730@BY2PR21MB0036.namprd21.prod.outlook.com>
Date:   Sun, 22 Jan 2017 18:19:24 +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 03:43:09PM +0000, Matthew Wilcox wrote:
> > In the case of a network filesystem being used to communicate with
> > a different VM on the same physical machine, there is no backing
> > device, just a network protocol.
> 
> Again, do you mean block device?  For a filesystem that does not do any
> pagecache writeback we already don't need a backing device, so I don't
> really see an issue there to start with.

No, I mean a network filesystem like 9p or cifs or nfs.  If the memcpy is supposed to be performed by the backing device and there is no backing device, then it's going to need to be done by the network filesystem.

(Also, the network filesystem might have a command, like RDMA has/will have, to ensure that the write has reached persistence)