linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Naohiro Aota <Naohiro.Aota@wdc.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	WenRuo Qu <wqu@suse.com>, hch <hch@lst.de>
Subject: Re: [PATCH] btrfs: fix error propagation of split bios
Date: Thu, 10 Oct 2024 13:02:34 +0200	[thread overview]
Message-ID: <20241010110234.GO1609@suse.cz> (raw)
In-Reply-To: <l37wmp4eebrjz3be5nbezvpdz3dm4u2ilru647yjh3dzjkbg4u@wtxtu4hxuyf4>

On Thu, Oct 10, 2024 at 05:51:50AM +0000, Naohiro Aota wrote:
> > > -		if (bbio->bio.bi_status)
> > > -			btrfs_bbio_propagate_error(bbio, orig_bbio);
> > > +		/* Save the last error. */
> > > +		if (bbio->bio.bi_status != BLK_STS_OK)
> > > +			atomic_set(&orig_bbio->status, bbio->bio.bi_status);
> > >  		btrfs_cleanup_bio(bbio);
> > >  		bbio = orig_bbio;
> > >  	}
> > >  
> > > -	if (atomic_dec_and_test(&bbio->pending_ios))
> > > +	if (atomic_dec_and_test(&bbio->pending_ios)) {
> > > +		/* Load split bio's error which might be set above. */
> > > +		if (status == BLK_STS_OK)
> > > +			bbio->bio.bi_status = atomic_read(&bbio->status);
> > >  		__btrfs_bio_end_io(bbio);
> > > +	}
> > >  }
> > >  
> > >  static int next_repair_mirror(struct btrfs_failed_bio *fbio, int cur_mirror)
> > > diff --git a/fs/btrfs/bio.h b/fs/btrfs/bio.h
> > > index e48612340745..b8f7f6071bc2 100644
> > > --- a/fs/btrfs/bio.h
> > > +++ b/fs/btrfs/bio.h
> > > @@ -79,6 +79,9 @@ struct btrfs_bio {
> > >  	/* File system that this I/O operates on. */
> > >  	struct btrfs_fs_info *fs_info;
> > >  
> > > +	/* Set the error status of split bio. */
> > > +	atomic_t status;
> > 
> > To repeat my comments from slack here. This should not be atomic when
> > it's using only set and read, a plain int or blk_sts_t.
> 
> Yes, I'll change this to blk_status_t for better understanding.
> 
> > 
> > The logic of storing the last error in btrfs_bio makes sense, I don't
> > see other ways to do it. If there are multiple errors we can store the
> > first one or the last one, we'd always lose some information. When it's
> > the first one it could be set by cmpxchg.
> 
> Sure. I'll use cmpxchg to save the first one.

The type blk_status_t is a u8, this works with cmpxchg, at least on
x86_64 and the common architectures.

  reply	other threads:[~2024-10-10 11:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09 15:57 [PATCH] btrfs: fix error propagation of split bios Naohiro Aota
2024-10-09 16:59 ` David Sterba
2024-10-10  5:51   ` Naohiro Aota
2024-10-10 11:02     ` David Sterba [this message]
2024-10-09 21:38 ` Qu Wenruo
2024-10-09 21:40   ` Qu Wenruo
2024-10-09 21:58   ` Qu Wenruo
2024-10-09 23:11     ` Qu Wenruo
2024-10-10  7:06       ` Christoph Hellwig
2024-10-10  8:53         ` Naohiro Aota
2024-10-10  9:45           ` hch
2024-10-12  6:12 ` kernel test robot

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=20241010110234.GO1609@suse.cz \
    --to=dsterba@suse.cz \
    --cc=Naohiro.Aota@wdc.com \
    --cc=hch@lst.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /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;
as well as URLs for NNTP newsgroup(s).