On Tue, 2016-06-21 at 09:25 -0700, Dan Williams wrote: > On Tue, Jun 21, 2016 at 8:44 AM, Kani, Toshimitsu <toshi.kani@xxxxxxx> > wrote: > > > > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at 6:22pm -0400, > > > Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > > > > > > On Mon, Jun 20 2016 at 5:28pm -0400, > > > > Kani, Toshimitsu <toshi.kani@xxxxxxx> wrote: > > : > > > > Looks good, I folded it in and tested it to work. Pushed to my 'wip' > > > > branch. > > > > > > > > No longer seeing any corruption in my test that was using partitions > > > > to span pmem devices with a dm-linear device. > > > > > > > > Jens, any chance you'd be open to picking up the first 2 patches in > > > > this series? Or would you like to see them folded or something > > > > different? > > > > > > I'm now wondering if we'd be better off setting a new QUEUE_FLAG_DAX > > > rather than establish GENHD_FL_DAX on the genhd? > > > > > > It'd be quite a bit easier to allow upper layers (e.g. XFS and ext4) to > > > check for a queue flag. > > > > I think GENHD_FL_DAX is more appropriate since DAX does not use a request > > queue, except for protecting the underlining device being disabled while > > direct_access() is called (b2e0d1625e19). > > > > About protecting direct_access, this patch assumes that the underlining > > device cannot be disabled until dtr() is called. Is this correct? If > > not, I will need to call dax_map_atomic(). > > Kernel internal usages of dax should be using dax_map_atomic() to > safely resolve device removal races. Will do. In such case, shall I move dax_[un]map_atomic() to block_dev.c and rename them to bdev_dax_[un]map_atomic()? Thanks, -Toshi -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
