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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
