On Wed, Jun 03, 2020 at 12:10:24PM +0200, Jan Kara wrote:

On Tue 02-06-20 10:23:53, Darrick J. Wong wrote:

quoted

On Tue, Apr 28, 2020 at 01:11:38PM -0700, Darrick J. Wong wrote:

quoted

quoted

-out_unlock:
-	xfs_iunlock(ip, XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL);
-	return error;
+	if ((mp->m_flags & XFS_MOUNT_DAX_ALWAYS) ||
+	    (mp->m_flags & XFS_MOUNT_DAX_NEVER))
+		return;
 
+	if (((fa->fsx_xflags & FS_XFLAG_DAX) &&
+	    !(ip->i_d.di_flags2 & XFS_DIFLAG2_DAX)) ||
+	    (!(fa->fsx_xflags & FS_XFLAG_DAX) &&
+	     (ip->i_d.di_flags2 & XFS_DIFLAG2_DAX)))
+		d_mark_dontcache(inode);

Now that I think about this further, are we /really/ sure that we want
to let unprivileged userspace cause inode evictions?

You have to have an equivalent of write access to the file to be able to
trigger d_mark_dontcache(). So you can e.g. delete it.  Or you could
fadvise / madvise regarding its page cache. I don't see the ability to push
inode out of cache as stronger than the abilities you already have...

<nod> Ok.  I just had one last bout of paranoia, but I think it'll be
fine. :)

--D

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR