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 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.