All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 4/5] btrfs: fail transaction when a setget bounds check failure is detected
Date: Fri, 4 Feb 2022 13:38:53 +0000	[thread overview]
Message-ID: <Yf0sbW/Br3am+eTE@debian9.Home> (raw)
In-Reply-To: <Yf0OLxcQ5mxiwWM5@debian9.Home>

On Fri, Feb 04, 2022 at 11:29:51AM +0000, Filipe Manana wrote:
> On Thu, Feb 03, 2022 at 06:26:31PM +0100, David Sterba wrote:
> > As the setget check only sets the bit, we need to use it in the
> > transaction:
> > 
> > - when attempting to start a new one, fail with EROFS as if would be
> >   aborted in another way already
> > 
> > - in should_end_transaction
> > 
> > - when transaction is about to end, insert an explicit abort
> > 
> > Signed-off-by: David Sterba <dsterba@suse.com>
> > ---
> >  fs/btrfs/transaction.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
> > index 6db634ebae17..f48194df6c33 100644
> > --- a/fs/btrfs/transaction.c
> > +++ b/fs/btrfs/transaction.c
> > @@ -591,6 +591,9 @@ start_transaction(struct btrfs_root *root, unsigned int num_items,
> >  	if (BTRFS_FS_ERROR(fs_info))
> >  		return ERR_PTR(-EROFS);
> >  
> > +	if (test_bit(BTRFS_FS_SETGET_COMPLAINS, &fs_info->flags))
> > +		return ERR_PTR(-EROFS);
> > +
> >  	if (current->journal_info) {
> >  		WARN_ON(type & TRANS_EXTWRITERS);
> >  		h = current->journal_info;
> > @@ -924,6 +927,9 @@ static bool should_end_transaction(struct btrfs_trans_handle *trans)
> >  {
> >  	struct btrfs_fs_info *fs_info = trans->fs_info;
> >  
> > +	if (test_bit(BTRFS_FS_SETGET_COMPLAINS, &fs_info->flags))
> > +		return true;
> > +
> >  	if (btrfs_check_space_for_delayed_refs(fs_info))
> >  		return true;
> >  
> > @@ -969,6 +975,11 @@ static int __btrfs_end_transaction(struct btrfs_trans_handle *trans,
> >  	struct btrfs_transaction *cur_trans = trans->transaction;
> >  	int err = 0;
> >  
> > +	/* If a serious error was detected abort the transaction early */
> > +	if (!TRANS_ABORTED(trans) &&
> > +	    test_bit(BTRFS_FS_SETGET_COMPLAINS, &info->flags))
> > +		btrfs_abort_transaction(trans, -EIO);
> 
> Instead of sprinkling the test for BTRFS_FS_SETGET_COMPLAINS in all
> these places, it seems to me it could be included in BTRFS_FS_ERROR().
> And then having check_setget_bounds() call btrfs_handle_fs_error().
> 
> That would remove the need for all this code. Wouldn't it?

In fact just calling btrfs_handle_fs_error() at report_setget_bounds()
or check_setget_bounds() would be all that is needed.
No need for adding the flag BTRFS_FS_SETGET_COMPLAINS, checking for it
at several places, then aborting transaction in those places, etc.

Way more simple and less intrusive.

> 
> > +
> >  	if (refcount_read(&trans->use_count) > 1) {
> >  		refcount_dec(&trans->use_count);
> >  		trans->block_rsv = trans->orig_rsv;
> 
> This misses one important case:
> 
>   task starts/joins/attaches a transaction
> 
>   fails one of the bounds check when accessing some extent buffer
> 
>   calls btrfs_commit_transaction()
> 
> The transaction ends up committed.
> 
> So a check and abort in the commit path, right before writing the super blocks,
> should be in place.
> 
> With the above suggestions for check_setget_bounds() and BTRFS_FS_ERROR(),
> this case would be handled automatically like the others, so no need for
> sprinkling the checks and aborts in several places.
> 
> Thanks.
> 
> > -- 
> > 2.34.1
> > 

  reply	other threads:[~2022-02-04 13:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 17:26 [PATCH 0/5] Speedups and check_setget_bounds reporting updates David Sterba
2022-02-03 17:26 ` [PATCH 1/5] btrfs: remove redundant check in up check_setget_bounds David Sterba
2022-02-10 17:52   ` David Sterba
2022-02-03 17:26 ` [PATCH 2/5] btrfs: factor out reporting when check_setget_bounds fails David Sterba
2022-02-03 17:26 ` [PATCH 3/5] btrfs: store details about first setget bounds check failure David Sterba
2022-02-04 11:31   ` Filipe Manana
2022-02-10 17:27     ` David Sterba
2022-02-03 17:26 ` [PATCH 4/5] btrfs: fail transaction when a setget bounds check failure is detected David Sterba
2022-02-04 11:29   ` Filipe Manana
2022-02-04 13:38     ` Filipe Manana [this message]
2022-02-10 17:50     ` David Sterba
2022-02-11 11:23       ` Filipe Manana
2022-02-03 17:26 ` [PATCH 5/5] btrfs: move check_setget_bounds out of ASSERT David Sterba
2022-02-04  8:35 ` [PATCH 0/5] Speedups and check_setget_bounds reporting updates Johannes Thumshirn

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=Yf0sbW/Br3am+eTE@debian9.Home \
    --to=fdmanana@kernel.org \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@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.