On Tue, Jun 21, 2016 at 9:35 AM, Kani, Toshimitsu <toshi.kani@xxxxxxx> wrote: > 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()? Sounds good to me. I know Jeff and Christoph don't like the current calling convention of passing in a structure. Just note that they might ask you to change it back to a list of parameters if it moves to bdev_dax_map_atomic(). -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
