On Mon, Aug 26, 2024 at 10:41:18AM +1000, Dave Chinner wrote:
> On Thu, Aug 22, 2024 at 05:04:14PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@xxxxxxxxxx>
> >
> > Metadata inodes are private files and therefore cannot be exposed to
> > userspace. This means no bulkstat, no open-by-handle, no linking them
> > into the directory tree, and no feeding them to LSMs. As such, we mark
> > them S_PRIVATE, which stops all that.
>
> Can you merge this back up into the initial iget support code?
>
> >
> > While we're at it, put them in a separate lockdep class so that it won't
> > get confused by "recursive" i_rwsem locking such as what happens when we
> > write to a rt file and need to allocate from the rt bitmap file. The
> > static function that we use to do this will be exported in the rtgroups
> > patchset.
>
> Stale commit message? There's nothing of the sort in this patch....
Yeah, sorry. Previously there were separate lockdep classes for metadir
directories and files each, but hch and I decided that each consumer of
a metadata file should set its own class accordingly, and that the
directories could continue using xfs_nondir_ilock_class as the only
code that uses them is either mount time setup code or repair.
> >
> > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
> > ---
> > fs/xfs/scrub/tempfile.c | 8 ++++++++
> > fs/xfs/xfs_iops.c | 15 ++++++++++++++-
> > 2 files changed, 22 insertions(+), 1 deletion(-)
> >
> >
> > diff --git a/fs/xfs/scrub/tempfile.c b/fs/xfs/scrub/tempfile.c
> > index 177f922acfaf1..3c5a1d77fefae 100644
> > --- a/fs/xfs/scrub/tempfile.c
> > +++ b/fs/xfs/scrub/tempfile.c
> > @@ -844,6 +844,14 @@ xrep_is_tempfile(
> > const struct xfs_inode *ip)
> > {
> > const struct inode *inode = &ip->i_vnode;
> > + struct xfs_mount *mp = ip->i_mount;
> > +
> > + /*
> > + * Files in the metadata directory tree also have S_PRIVATE set and
> > + * IOP_XATTR unset, so we must distinguish them separately.
> > + */
> > + if (xfs_has_metadir(mp) && (ip->i_diflags2 & XFS_DIFLAG2_METADATA))
> > + return false;
>
> Why do you need to check both xfs_has_metadir() and the inode flag
> here? The latter should only be set if the former is set, yes?
> If it's the other way around, then we have an on-disk corruption...
Probably just stale code that's been sitting around for a while.
But yes, this could all be:
if (xfs_is_metadir_inode(ip))
return false;
since the inode verifier should have already caught this.
> > if (IS_PRIVATE(inode) && !(inode->i_opflags & IOP_XATTR))
> > return true;
>
> > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> > index 1cdc8034f54d9..c1686163299a0 100644
> > --- a/fs/xfs/xfs_iops.c
> > +++ b/fs/xfs/xfs_iops.c
> > @@ -42,7 +42,9 @@
> > * held. For regular files, the lock order is the other way around - the
> > * mmap_lock is taken during the page fault, and then we lock the ilock to do
> > * block mapping. Hence we need a different class for the directory ilock so
> > - * that lockdep can tell them apart.
> > + * that lockdep can tell them apart. Directories in the metadata directory
> > + * tree get a separate class so that lockdep reports will warn us if someone
> > + * ever tries to lock regular directories after locking metadata directories.
> > */
> > static struct lock_class_key xfs_nondir_ilock_class;
> > static struct lock_class_key xfs_dir_ilock_class;
> > @@ -1299,6 +1301,7 @@ xfs_setup_inode(
> > {
> > struct inode *inode = &ip->i_vnode;
> > gfp_t gfp_mask;
> > + bool is_meta = xfs_is_metadata_inode(ip);
> >
> > inode->i_ino = ip->i_ino;
> > inode->i_state |= I_NEW;
> > @@ -1310,6 +1313,16 @@ xfs_setup_inode(
> > i_size_write(inode, ip->i_disk_size);
> > xfs_diflags_to_iflags(ip, true);
> >
> > + /*
> > + * Mark our metadata files as private so that LSMs and the ACL code
> > + * don't try to add their own metadata or reason about these files,
> > + * and users cannot ever obtain file handles to them.
> > + */
> > + if (is_meta) {
> > + inode->i_flags |= S_PRIVATE;
> > + inode->i_opflags &= ~IOP_XATTR;
> > + }
>
> No need for a temporary variable here.
<nod>
--D
> -Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
