linux-kernel - RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes

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:   Sat, 10 Sep 2016 07:50:09 +0000
From:   Matthew Wilcox <mawilcox@...rosoft.com>
To:     Christoph Hellwig <hch@...radead.org>,
        Dan Williams <dan.j.williams@...el.com>
CC:     Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Theodore Ts'o <tytso@....edu>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "linux-nvdimm@...1.01.org" <linux-nvdimm@...1.01.org>,
        Dave Chinner <david@...morbit.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "Andreas Dilger" <adilger.kernel@...ger.ca>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Jan Kara <jack@...e.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes

From: Christoph Hellwig [mailto:hch@...radead.org]
> On Fri, Sep 09, 2016 at 03:34:43PM -0700, Dan Williams wrote:
> > I agree with you that continuing to touch ext2 is not a good idea, but
> > I'm not yet convinced that now is the time to go do dax-2.0 when we
> > haven't finished shipping dax-1.0.
> 
> I've mentioned this before, but I'd like to repeat it.  With all the work reqwuired
> in the file system I would prefer to drop DAX support in ext2 (and if people
> really cry for it reinstate the trivial old xip support).

That allegedly trivial old xip support was horrendously broken.  And, er, it used an aop
which you seem implacably opposed to in your earlier email.  And that was truly a
disgusting one from a layering point of view.  Let me remind you:

-       int (*get_xip_mem)(struct address_space *, pgoff_t, int,
-                                               void **, unsigned long *);

That void ** was an 'out' parameter to store a kernel address for the memory.  The
unsigned long * was also an 'out' parameter to store the PFN for the memory.  The
'int' was actually a Boolean for whether to create or not, but you'd actually have to
go look at the implementation to find that out; the documentation never said it.  A
real dog's breakfast of an API.