[05/11] xfs: set XFS_DA_OP_OKNOENT in xfs_attr_get
diff mbox

Message ID 147828423671.31492.10920798285495163593.stgit@birch.djwong.org
State Accepted
Headers show

Commit Message

Eric Sandeen Nov. 4, 2016, 6:30 p.m. UTC
From c400ee3ed1b13d45adde68e12254dc6ab6977b59 Mon Sep 17 00:00:00 2001

It's entirely possible for userspace to ask for an xattr which
does not exist.

Normally, there is no problem whatsoever when we ask for such
a thing, but when we look at an obfuscated metadump image
on a debug kernel with selinux, we trip over this ASSERT in
xfs_da3_path_shift():

        *result = -ENOENT;      /* we're out of our tree */
        ASSERT(args->op_flags & XFS_DA_OP_OKNOENT);

It (more or less) only shows up in the above scenario, because
xfs_metadump obfuscates attr names, but chooses names which
keep the same hash value - and xfs_da3_node_lookup_int does:

        if (((retval == -ENOENT) || (retval == -ENOATTR)) &&
            (blk->hashval == args->hashval)) {
                error = xfs_da3_path_shift(state, &state->path, 1, 1,
                                                 &retval);

IOWS, we only get down to the xfs_da3_path_shift() ASSERT
if we are looking for an xattr which doesn't exist, but we
find xattrs on disk which have the same hash, and so might be
a hash collision, so we try the path shift.  When *that*
fails to find what we're looking for, we hit the assert about
XFS_DA_OP_OKNOENT.

Simply setting XFS_DA_OP_OKNOENT in xfs_attr_get solves this
rather corner-case problem with no ill side effects.  It's
fine for an attr name lookup to fail.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
---
 libxfs/xfs_attr.c |    2 ++
 1 file changed, 2 insertions(+)



--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Dave Chinner Nov. 6, 2016, 10:20 p.m. UTC | #1
Darrick,

There's something whacky with what you are doing to create these
commit messages. The from address on the email itself is not from
you (how did that get through SPF checks?) and instead there's this:

On Fri, Nov 04, 2016 at 11:30:36AM -0700, Eric Sandeen wrote:
> >From c400ee3ed1b13d45adde68e12254dc6ab6977b59 Mon Sep 17 00:00:00 2001

Which tells me nothing useful about the origin of the patch and it
means I have to mangle the commit message before committing it.

If you look at the libxfs sync commits that I applied for the
4.9-rc1 sync, the libxfs-apply script ends up formating the commits
like this:

ommit ece930fa14a3439e40cd1b43063cab5b85ab9407
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Oct 25 12:59:46 2016 +1100

    xfs: refactor xfs_bunmapi_cow
    
    Source kernel commit: fa5c836ca8eb5bad6316ddfc066acbc4e2485356
    
    Split out two helpers for deleting delayed or real extents from the COW fork.
    This allows to call them directly from xfs_reflink_cow_end_io once that
    function is refactored to iterate the extent tree.  It will also allow
    to reuse the delalloc deletion from xfs_bunmapi in the future.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>


So there's a clear line where the orginal commit came from. It does
this automatically now (see the fixup_header_format() function) so
that this sort of things doesn't need to be cleaned up after the
fact. If the commit is from xfsprogs and going to the kernel, it
will say "Source xfsprogs commit: ....." instead.  This way it is
clear to the reader that this commit is simply a libxfs sync commit,
and that the sob and rvb tags applied to the commit in the source
repository.

Perhaps you are using an older version of the script to generate
these commits?

Cheers,

Dave.

Patch
diff mbox

diff --git a/libxfs/xfs_attr.c b/libxfs/xfs_attr.c
index c7f0afa..60513f9 100644
--- a/libxfs/xfs_attr.c
+++ b/libxfs/xfs_attr.c
@@ -135,6 +135,8 @@  xfs_attr_get(
 
 	args.value = value;
 	args.valuelen = *valuelenp;
+	/* Entirely possible to look up a name which doesn't exist */
+	args.op_flags = XFS_DA_OP_OKNOENT;
 
 	lock_mode = xfs_ilock_attr_map_shared(ip);
 	if (!xfs_inode_hasattr(ip))