On Tue, Jun 26 2018 at 1:59pm -0400, Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> wrote: > This series fixes a few issues that I found with DM's handling of DAX > devices. Here are some of the issues I found: > > * We can create a dm-stripe or dm-linear device which is made up of an > fsdax PMEM namespace and a raw PMEM namespace but which can hold a > filesystem mounted with the -o dax mount option. DAX operations to > the raw PMEM namespace part lack struct page and can fail in > interesting/unexpected ways when doing things like fork(), examining > memory with gdb, etc. > > * We can create a dm-stripe or dm-linear device which is made up of an > fsdax PMEM namespace and a BRD ramdisk which can hold a filesystem > mounted with the -o dax mount option. All I/O to this filesystem > will fail. > > --- > > Changes since v2: > * Only set QUEUE_FLAG_DAX for fsdax mode PMEM namespaces. (Mike) > * Check for QUEUE_FLAG_DAX in __bdev_dax_supported(). (Mike) > * Get rid of DM_TYPE_DAX_BIO_BASED reworks. (Mike) > * Dropped the first 2 prep patches of v2 since they were merged for > v4.18-rc1. (Thanks, Darrick!) > > --- > > Mike, can you take this series through your tree? > > Personally I think this should be treated as a bug fix and merged in the > v4.18-rc* series. I'd be fine with staging it for 4.18. Only question is whether others are fine with the dax patch (and me being the one to get it to Linus)? I already replied to the 3rd patch with some feedback for v4 (but I can also take care of those changes if I'm the one to stage these changes). Maybe if Dan and/or others could provide their review for both the dax and pmem patches? If I can get review on those I'll get the series staged for Linus to pull this week. Thanks, Mike
