On Tue 02-06-20 10:23:53, Darrick J. Wong wrote: > On Tue, Apr 28, 2020 at 01:11:38PM -0700, Darrick J. Wong wrote: > > > -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... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
