On Tue, 2016-06-21 at 09:45 -0700, Dan Williams wrote: > 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: > > > > : > > > > 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(). OK, I will change it back to a list of parameters as well. Thanks, -Toshi -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
