On Wed, Oct 04, 2017 at 10:49:13AM +1100, Dave Chinner wrote:
> On Tue, Oct 03, 2017 at 01:41:20PM -0700, Darrick J. Wong wrote:
> > +/* btree scrubbing */
> > +
> > +/*
> > + * Check for btree operation errors. See the section about handling
> > + * operational errors in common.c.
> > + */
> > +bool
> > +xfs_scrub_btree_op_ok(
> > + struct xfs_scrub_context *sc,
> > + struct xfs_btree_cur *cur,
> > + int level,
> > + int *error)
> > +{
> ......
> > +
> > +/*
> > + * Visit all nodes and leaves of a btree. Check that all pointers and
> > + * records are in order, that the keys reflect the records, and use a callback
> > + * so that the caller can verify individual records. The callback is the same
> > + * as the one for xfs_btree_query_range, so therefore this function also
> > + * returns XFS_BTREE_QUERY_RANGE_ABORT, zero, or a negative error code.
> > + */
> > +int
> > +xfs_scrub_btree(
> > + struct xfs_scrub_context *sc,
> > + struct xfs_btree_cur *cur,
> > + xfs_scrub_btree_rec_fn scrub_fn,
> > + struct xfs_owner_info *oinfo,
> > + void *private)
> > +{
> > + xfs_scrub_btree_op_ok(sc, cur, 0, false);
>
> Looks like this patch won't compile - it's passing a bool to an int
> *. I know it's just a stub and probably gets fixed later, but
> better not to leave a bisect landmine...
Frighteningly it /does/ compile because the 'false' apparently gets
converted to NULL and therefore there's no type error. Fortunately
there are no callers so it'll never blow up... but hey, I'll fix it
anyway. Good catch!
--D
>
> -Dave
> --
> 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
--
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
