| Message ID | 147830451072.26713.4807330905355527976.stgit@birch.djwong.org (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Fri, Nov 04, 2016 at 05:08:30PM -0700, Eric Sandeen wrote: > >From c400ee3ed1b13d45adde68e12254dc6ab6977b59 Mon Sep 17 00:00:00 2001 It should claim to be from Eric here I think.. And mention that it's a port from a kernel commit. Otherwise looks fine: Reviewed-by: Christoph Hellwig <hch@lst.de> -- 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
On 11/15/16 4:16 AM, Christoph Hellwig wrote: > On Fri, Nov 04, 2016 at 05:08:30PM -0700, Eric Sandeen wrote: >> >From c400ee3ed1b13d45adde68e12254dc6ab6977b59 Mon Sep 17 00:00:00 2001 > > It should claim to be from Eric here I think.. > And mention that it's a port from a kernel commit. I suppose - do we have a clear policy on that? What should the format be for kernel<->userspace cross-ports in terms of From:, SoB:, etc? I guess the libxfs-apply script in tools/ implicitly defines that, i.e. - # We want to format it like a normal patch with a line to say what repo # and commit it was sourced from: # # xfs: make several functions static # # From: Eric Sandeen <sandeen@sandeen.net> # # Source kernel commit: 0d5a75e9e23ee39cd0d8a167393dcedb4f0f47b2 # # <body> -Eric > Otherwise looks fine: > > Reviewed-by: Christoph Hellwig <hch@lst.de> > -- 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
On Tue, Nov 15, 2016 at 07:41:19AM -0600, Eric Sandeen wrote: > On 11/15/16 4:16 AM, Christoph Hellwig wrote: > > On Fri, Nov 04, 2016 at 05:08:30PM -0700, Eric Sandeen wrote: > >> >From c400ee3ed1b13d45adde68e12254dc6ab6977b59 Mon Sep 17 00:00:00 2001 > > > > It should claim to be from Eric here I think.. > > > And mention that it's a port from a kernel commit. > > I suppose - do we have a clear policy on that? What should the format > be for kernel<->userspace cross-ports in terms of From:, SoB:, etc? > > I guess the libxfs-apply script in tools/ implicitly defines that, i.e. - > > # We want to format it like a normal patch with a line to say what repo > # and commit it was sourced from: > # > # xfs: make several functions static > # > # From: Eric Sandeen <sandeen@sandeen.net> > # > # Source kernel commit: 0d5a75e9e23ee39cd0d8a167393dcedb4f0f47b2 > # > # <body> Yes, exactly. I asked Darricki last week to regenerate the patches with this commit message problem using the libxfs-apply tool as it handles all this commit reference/orignal author reformatting automatically now. Cheers, Dave.
On Wed, Nov 16, 2016 at 04:21:16PM +1100, Dave Chinner wrote: > On Tue, Nov 15, 2016 at 07:41:19AM -0600, Eric Sandeen wrote: > > On 11/15/16 4:16 AM, Christoph Hellwig wrote: > > > On Fri, Nov 04, 2016 at 05:08:30PM -0700, Eric Sandeen wrote: > > >> >From c400ee3ed1b13d45adde68e12254dc6ab6977b59 Mon Sep 17 00:00:00 2001 > > > > > > It should claim to be from Eric here I think.. > > > > > And mention that it's a port from a kernel commit. > > > > I suppose - do we have a clear policy on that? What should the format > > be for kernel<->userspace cross-ports in terms of From:, SoB:, etc? > > > > I guess the libxfs-apply script in tools/ implicitly defines that, i.e. - > > > > # We want to format it like a normal patch with a line to say what repo > > # and commit it was sourced from: > > # > > # xfs: make several functions static > > # > > # From: Eric Sandeen <sandeen@sandeen.net> > > # > > # Source kernel commit: 0d5a75e9e23ee39cd0d8a167393dcedb4f0f47b2 > > # > > # <body> > > Yes, exactly. I asked Darricki last week to regenerate the patches > with this commit message problem using the libxfs-apply tool as it > handles all this commit reference/orignal author reformatting > automatically now. Heh, I fixed up the patches and forgot to send out v2 patches. I'll do that now. --D > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > -- > 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 -- 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
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