| Message ID | 147828423671.31492.10920798285495163593.stgit@birch.djwong.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
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.
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))
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