Re: [PATCH 11/13] xfs: fail out of xfs_attr3_leaf_lookup_int if it looks corrupt

[Dave Chinner <david@fromorbit.com>]

On Wed, Dec 13, 2017 at 03:59:19PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> If the xattr leaf block looks corrupt, return -EFSCORRUPTED to userspace
> instead of ASSERTing on debug kernels or running off the end of the
> buffer on regular kernels.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
>  fs/xfs/libxfs/xfs_attr_leaf.c |    9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

> 
> 
> diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c
> index a5033f0..e130952 100644
> --- a/fs/xfs/libxfs/xfs_attr_leaf.c
> +++ b/fs/xfs/libxfs/xfs_attr_leaf.c
> @@ -2246,7 +2246,8 @@ xfs_attr3_leaf_lookup_int(
>  	leaf = bp->b_addr;
>  	xfs_attr3_leaf_hdr_from_disk(args->geo, &ichdr, leaf);
>  	entries = xfs_attr3_leaf_entryp(leaf);
> -	ASSERT(ichdr.count < args->geo->blksize / 8);
> +	if (ichdr.count >= args->geo->blksize / 8)
> +		return -EFSCORRUPTED;

I was wondering exactly what the "/ 8" is for, but I think it's just
a rough calculation of maximum number of leaf entries taht can be in
the block. Doesn't matter right now - this is still better than
assert failures....

So, look fine,

Reviewed-by: Dave Chinner <dchinner@redhat.com>

-- 
Dave Chinner
david@fromorbit.com