On Mon, Jan 13, 2020 at 02:19:57PM -0800, Darrick J. Wong wrote: > On Fri, Jan 10, 2020 at 11:29:38AM -0800, ira.weiny@xxxxxxxxx wrote: > > From: Ira Weiny <ira.weiny@xxxxxxxxx> > > [snip] > > > > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > > index 401da197f012..e8fd95b75e5b 100644 > > --- a/fs/xfs/xfs_inode.c > > +++ b/fs/xfs/xfs_inode.c > > @@ -142,12 +142,12 @@ xfs_ilock_attr_map_shared( > > * > > * Basic locking order: > > * > > - * i_rwsem -> i_mmap_lock -> page_lock -> i_ilock > > + * i_rwsem -> i_dax_sem -> i_mmap_lock -> page_lock -> i_ilock > > Mmmmmm, more locks. Can we skip the extra lock if CONFIG_FSDAX=n or if > the filesystem devices don't support DAX at all? I've looked into this a bit more and I think skipping on CONFIG_FSDAX=n is ok but doing so on individual devices is not going to be possible because we don't have that information at the vfs layer. I'll continue to think about how to mitigate this more while I add CONFIG_FSDAX checks before rolling out a new patch set. > > Also, I don't think we're actually following the i_rwsem -> i_daxsem > order in fallocate, and possibly elsewhere too? > > Does the vfs have to take the i_dax_sem to do remapping things like > reflink? (Pretend that reflink and dax are compatible for the moment) > I spoke with Dan today about this and we believe the answer is going to be yes. However, not until the code is added to support DAX in reflink. Because currently this is only required for places which use "IS_DAX()" to see the state of the inode. Currently the vfs layer does not have any IS_DAX() checks in the reflink path. But when they are added they will be required to take this sem. Ira
