Re: [PATCH V11 11/11] fs/xfs: Update xfs_ioctl_setattr_dax_invalidate()

Darrick J. Wong
2020-06-03T17:04:15Z

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:
> > 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...

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

--D

> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR