Re: [PATCH 06/20] xfs: have buffer verifier functions report failing address

[Dave Chinner <david@fromorbit.com>]

On Fri, Dec 22, 2017 at 05:07:41PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Modify each function that checks the contents of a metadata buffer to
> return the instruction address of the failing test so that we can report
> more precise failure errors to the log.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
......
> @@ -211,17 +211,34 @@ __xfs_dir3_data_check(
>  				stale++;
>  			if (i > 0 && be32_to_cpu(lep[i].hashval) <
>  				     be32_to_cpu(lep[i - 1].hashval))
> -				return false;
> +				return __this_address;
>  		}
>  		if (count != be32_to_cpu(btp->count) - be32_to_cpu(btp->stale))
> -			return false;
> +			return __this_address;
>  		if (stale != be32_to_cpu(btp->stale))
> -			return false;
> +			return __this_address;
>  	}
> -	return true;
> +	return NULL;
>  }
>  
> -static bool
> +#ifdef DEBUG
> +void
> +xfs_dir3_data_check(
> +	struct xfs_inode	*dp,
> +	struct xfs_buf		*bp)
> +{
> +	xfs_failaddr_t		fa;
> +
> +	fa = __xfs_dir3_data_check(dp, bp);
> +	if (!fa)
> +		return;
> +	xfs_corruption_error(__func__, XFS_ERRLEVEL_LOW, dp->i_mount,
> +			bp->b_addr, __FILE__, __LINE__, fa);
> +	ASSERT(0);
> +}
> +#endif

So the only concern I have here is what {__FILE__, __LINE__} resolve
to. The macro gave us call site file/line, while this only gives us
the file/line in xfs_dir3_data_check(). Hence we won't know from the
corruption output what call to xfs_dir3_data_check() generated the
report. We can turn the error level up if we want a stack trace on
error from a production machine, so I can live with this.

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

-- 
Dave Chinner
david@fromorbit.com