public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/4] xfs: fix buffer state when we reject a corrupt dir free block
Date: Tue, 3 Mar 2020 08:38:53 -0800	[thread overview]
Message-ID: <20200303163853.GA8045@magnolia> (raw)
In-Reply-To: <e38b8334-6b64-71ed-62d6-527f0fe57f09@sandeen.net>

On Mon, Mar 02, 2020 at 05:54:07PM -0600, Eric Sandeen wrote:
> On 2/28/20 5:48 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Fix two problems in the dir3 free block read routine when we want to
> > reject a corrupt free block.  First, buffers should never have DONE set
> > at the same time that b_error is EFSCORRUPTED.  Second, don't leak a
> > pointer back to the caller.
> 
> For both of these things I'm left wondering; why does this particular
> location need to have XBF_DONE cleared after the verifier error?  Most
> other locations that mark errors don't do this.

Read verifier functions don't need to clear XBF_DONE because
xfs_buf_reverify will notice b_error being set, and clear XBF_DONE for
us.

__xfs_dir3_free_read calls _read_buf.  If the buffer read succeeds,
_free_read then has xfs_dir3_free_header_check do some more checking on
the buffer that we can't do in read verifiers.  This is *outside* the
regular read verifier (because we can't pass the owner into _read_buf)
so if we're going to use xfs_verifier_error() to set b_error then we
also have to clear XBF_DONE so that when we release the buffer a few
lines later the buffer will be in a state that the buffer code expects.

This isn't theoretical, if the _header_check fails then we start
tripping the b_error assert the next time someone calls
xfs_buf_reverify.

> xfs_inode_buf_verify does, but for readahead purposes:
> 
>  * If the readahead buffer is invalid, we need to mark it with an error and
>  * clear the DONE status of the buffer so that a followup read will re-read it
>  * from disk.
> 
> Also, what problem does setting the pointer to NULL solve?

This avoids returning to the caller a pointer to an xfs_buf that we
might have just released in xfs_trans_brelse.  The caller ought to bail
out on the EFSCORRUPTED return value, but let's be defensive anyway. :)

--D

> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  fs/xfs/libxfs/xfs_dir2_node.c |    2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > 
> > diff --git a/fs/xfs/libxfs/xfs_dir2_node.c b/fs/xfs/libxfs/xfs_dir2_node.c
> > index a0cc5e240306..f622ede7119e 100644
> > --- a/fs/xfs/libxfs/xfs_dir2_node.c
> > +++ b/fs/xfs/libxfs/xfs_dir2_node.c
> > @@ -227,7 +227,9 @@ __xfs_dir3_free_read(
> >  	fa = xfs_dir3_free_header_check(dp, fbno, *bpp);
> >  	if (fa) {
> >  		xfs_verifier_error(*bpp, -EFSCORRUPTED, fa);
> > +		(*bpp)->b_flags &= ~XBF_DONE;
> >  		xfs_trans_brelse(tp, *bpp);
> > +		*bpp = NULL;
> >  		return -EFSCORRUPTED;
> >  	}
> >  
> > 

  reply	other threads:[~2020-03-03 16:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-29  1:48 [PATCH 0/4] xfs: fix errors in directory verifiers Darrick J. Wong
2020-02-29  1:48 ` [PATCH 1/4] xfs: fix buffer state when we reject a corrupt dir free block Darrick J. Wong
2020-03-02 18:11   ` Allison Collins
2020-03-02 23:54   ` Eric Sandeen
2020-03-03 16:38     ` Darrick J. Wong [this message]
2020-03-03 17:43       ` Darrick J. Wong
2020-03-03 23:45       ` Dave Chinner
2020-03-05 17:45         ` Darrick J. Wong
2020-03-03 20:19   ` Darrick J. Wong
2020-03-05 16:49   ` Christoph Hellwig
2020-02-29  1:48 ` [PATCH 2/4] xfs: check owner of dir3 free blocks Darrick J. Wong
2020-03-02 18:11   ` Allison Collins
2020-03-03  0:04   ` Eric Sandeen
2020-03-03 16:08     ` Darrick J. Wong
2020-03-03 16:10       ` Eric Sandeen
2020-03-05 16:50   ` Christoph Hellwig
2020-02-29  1:48 ` [PATCH 3/4] xfs: check owner of dir3 data blocks Darrick J. Wong
2020-03-02 18:12   ` Allison Collins
2020-03-03 16:43     ` Darrick J. Wong
2020-03-05 16:50   ` Christoph Hellwig
2020-02-29  1:49 ` [PATCH 4/4] xfs: check owner of dir3 blocks Darrick J. Wong
2020-03-02 18:12   ` Allison Collins
2020-03-05 16:51   ` Christoph Hellwig
2020-03-05 17:48     ` Darrick J. Wong

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=20200303163853.GA8045@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox