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  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, 23 Jan 2017 09:14:04 -0800
From:   Dan Williams <>
To:     Christoph Hellwig <>
Cc:     Matthew Wilcox <>,
        "" <>,
        Tony Luck <>, Jan Kara <>,
        Toshi Kani <>,
        Mike Snitzer <>,
        "" <>,
        "" <>, Jeff Moyer <>,
        Jens Axboe <>,
        "" <>,
        Ingo Molnar <>,
        Al Viro <>,
        "H. Peter Anvin" <>,
        "" <>,
        Thomas Gleixner <>,
        Linus Torvalds <>,
        Ross Zwisler <>
Subject: Re: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Mon, Jan 23, 2017 at 8:00 AM, Christoph Hellwig <> wrote:
> On Sun, Jan 22, 2017 at 11:10:04PM -0800, Dan Williams wrote:
>> How about we solve the copy_from_user() abuse first before we hijack
>> this thread for some future feature that afaics has no patches posted
>> yet.
> Solving copy_from_user abuse first sounds perfectly fine to me.  But
> please do so without abusing the block layer for persistent memory
> access.  Given that we don't have use cases for different pmem access
> methods in a single OS image yet let's avoid introducing new ops
> for now and just remove the copy_from_user abuse.

The use case that we have now is distinguishing volatile vs persistent
memory (brd vs pmem).

I took a look at mtd layering approach and the main difference is that
layers above the block layer do not appear to know anything about mtd
specifics. For fs/dax.c we currently need some path to retrieve a dax
anchor object through the block device.

> In the longer run I like your dax_operations, but they need to be
> separate from the block layer.

I'll move them from block_device_operations to dax data hanging off of
the bdev_inode, or is there a better way to go from bdev-to-dax?

Powered by blists - more mailing lists