On Fri, Dec 22, 2017 at 05:07:41PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
>
> 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@xxxxxxxxxx>
......
> @@ -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@xxxxxxxxxx>
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
