summaryrefslogtreecommitdiffstats
path: root/lib/halfmd4.c
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2015-08-19 10:30:48 +1000
committerDave Chinner <david@fromorbit.com>2015-08-19 10:30:48 +1000
commitc400ee3ed1b13d45adde68e12254dc6ab6977b59 (patch)
tree304c25fe40dc95b9d00118189823ea43df5a14af /lib/halfmd4.c
parentce748eaa65f2e9392ba82726503c8d994ffd6393 (diff)
downloadop-kernel-dev-c400ee3ed1b13d45adde68e12254dc6ab6977b59.zip
op-kernel-dev-c400ee3ed1b13d45adde68e12254dc6ab6977b59.tar.gz
xfs: set XFS_DA_OP_OKNOENT in xfs_attr_get
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>
Diffstat (limited to 'lib/halfmd4.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud