All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs: actually check xfs_btree_check_block return in xfs_btree_islastblock
Date: Thu, 7 Nov 2019 23:29:51 -0800	[thread overview]
Message-ID: <20191108072951.GP6219@magnolia> (raw)
In-Reply-To: <20191108071441.GB31526@infradead.org>

On Thu, Nov 07, 2019 at 11:14:41PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2019 at 11:05:04PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Coverity points out that xfs_btree_islastblock calls
> > xfs_btree_check_block, but doesn't act on an error return.  This
> > predicate has no answer if the btree is corrupt, so tweak the helper to
> > be able to return errors, and then modify the one call site.
> 
> Could we just kill xfs_btree_islastblock?  It has pretty trivial, and
> only has a single caller which only uses on of the two branches in the
> function anyway.

I'd rather leave it as a btree primitive, honestly.

That said, "Is this cursor pointing to the last block on $level?" only
makes sense if you've already performed a lookup (or seek) operation.
If you've done that, you've already checked the block, right?  So I
think we could just get rid of the _check_block call on the grounds that
we already did that as part of the lookup (or turn it into an ASSERT),
and then this becomes a short enough function to try to make it a four
line static inline predicate.

Same result, but slightly better encapsulation.

(Yeah yeah, it's C, we're all one big happy family of bits...)

--D

  reply	other threads:[~2019-11-08  7:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08  7:04 [PATCH v2 0/3] xfs: various coverity fixes Darrick J. Wong
2019-11-08  7:04 ` [PATCH 1/3] xfs: annotate functions that trip static checker locking checks Darrick J. Wong
2019-11-08  7:05   ` Christoph Hellwig
2019-11-08  7:04 ` [PATCH 2/3] xfs: clean up weird while loop in xfs_alloc_ag_vextent_near Darrick J. Wong
2019-11-08  7:11   ` Christoph Hellwig
2019-11-08  7:20     ` Darrick J. Wong
2019-11-08  7:22       ` Christoph Hellwig
2019-11-08  7:05 ` [PATCH 3/3] xfs: actually check xfs_btree_check_block return in xfs_btree_islastblock Darrick J. Wong
2019-11-08  7:14   ` Christoph Hellwig
2019-11-08  7:29     ` Darrick J. Wong [this message]
2019-11-08  7:33       ` Christoph Hellwig
2019-11-08  7:46         ` Darrick J. Wong
2019-11-08  7:47   ` Darrick J. Wong
2019-11-18 10:59     ` Carlos Maiolino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191108072951.GP6219@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.