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.
next prev parent 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).