From: John Garry <john.g.garry@oracle.com>
To: axboe@kernel.dk, song@kernel.org, yukuai3@huawei.com, hch@lst.de
Cc: martin.petersen@oracle.com, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
hare@suse.de, Johannes.Thumshirn@wdc.com
Subject: Re: [PATCH v3 0/6] bio_split() error handling rework
Date: Thu, 7 Nov 2024 06:49:57 +0000 [thread overview]
Message-ID: <e0a82859-6c9e-43d4-b6ee-4b96fa193fa9@oracle.com> (raw)
In-Reply-To: <20241031095918.99964-1-john.g.garry@oracle.com>
On 31/10/2024 09:59, John Garry wrote:
Hi Jens,
Could you kindly consider picking up this series via the block tree?
Please note that the raid 0/1/10 atomic write support in
https://lore.kernel.org/linux-block/20241101144616.497602-1-john.g.garry@oracle.com/
depends on this series, so maybe you would also be willing to pick that
one up (when it's fully reviewed). Or create a branch with all the block
changes, like which was done for the atomic writes XFS support.
Thanks very much,
John
> bio_split() error handling could be improved as follows:
> - Instead of returning NULL for an error - which is vague - return a
> PTR_ERR, which may hint what went wrong.
> - Remove BUG_ON() calls - which are generally not preferred - and instead
> WARN and pass an error code back to the caller. Many callers of
> bio_split() don't check the return code. As such, for an error we would
> be getting a crash still from an invalid pointer dereference.
>
> Most bio_split() callers don't check the return value. However, it could
> be argued the bio_split() calls should not fail. So far I have just
> fixed up the md RAID code to handle these errors, as that is my interest
> now.
>
> The motivator for this series was initial md RAID atomic write support in
> https://lore.kernel.org/linux-block/20241030094912.3960234-1-john.g.garry@oracle.com/T/#m5859ee900de8e6554d5bb027c0558f0147c32df8
>
> There I wanted to ensure that we don't split an atomic write bio, and it
> made more sense to handle this in bio_split() (instead of the bio_split()
> caller).
>
> Based on 133008e84b99 (block/for-6.13/block) blk-integrity: remove
> seed for user mapped buffers
>
> Changes since v2:
> - Drop "block: Use BLK_STS_OK in bio_init()" change (Christoph)
> - Use proper rdev indexing in raid10_write_request() (Kuai)
> - Decrement rdev nr_pending in raid1 read error path (Kuai)
> - Add RB tags from Christoph, Johannes, and Kuai (thanks!)
>
> Changes since RFC:
> - proper handling to end the raid bio in all cases, and also pass back
> proper error code (Kuai)
> - Add WARN_ON_ERROR in bio_split() (Johannes, Christoph)
> - Add small patch to use BLK_STS_OK in bio_init()
> - Change bio_submit_split() error path (Christoph)
>
> John Garry (6):
> block: Rework bio_split() return value
> block: Error an attempt to split an atomic write in bio_split()
> block: Handle bio_split() errors in bio_submit_split()
> md/raid0: Handle bio_split() errors
> md/raid1: Handle bio_split() errors
> md/raid10: Handle bio_split() errors
>
> block/bio.c | 14 +++++++----
> block/blk-crypto-fallback.c | 2 +-
> block/blk-merge.c | 15 ++++++++----
> drivers/md/raid0.c | 12 ++++++++++
> drivers/md/raid1.c | 33 ++++++++++++++++++++++++--
> drivers/md/raid10.c | 47 ++++++++++++++++++++++++++++++++++++-
> 6 files changed, 110 insertions(+), 13 deletions(-)
>
next prev parent reply other threads:[~2024-11-07 6:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-31 9:59 [PATCH v3 0/6] bio_split() error handling rework John Garry
2024-10-31 9:59 ` [PATCH v3 1/6] block: Rework bio_split() return value John Garry
2024-11-05 7:21 ` Hannes Reinecke
2024-11-05 17:16 ` John Garry
2024-10-31 9:59 ` [PATCH v3 2/6] block: Error an attempt to split an atomic write in bio_split() John Garry
2024-11-05 7:22 ` Hannes Reinecke
2024-10-31 9:59 ` [PATCH v3 3/6] block: Handle bio_split() errors in bio_submit_split() John Garry
2024-11-05 7:23 ` Hannes Reinecke
2024-10-31 9:59 ` [PATCH v3 4/6] md/raid0: Handle bio_split() errors John Garry
2024-11-05 7:24 ` Hannes Reinecke
2024-10-31 9:59 ` [PATCH v3 5/6] md/raid1: " John Garry
2024-10-31 11:07 ` Yu Kuai
2024-11-05 7:26 ` Hannes Reinecke
2024-10-31 9:59 ` [PATCH v3 6/6] md/raid10: " John Garry
2024-10-31 11:11 ` Yu Kuai
2024-11-05 7:27 ` Hannes Reinecke
2024-11-07 6:49 ` [PATCH v3 0/6] bio_split() error handling rework John Garry
2024-11-07 6:49 ` John Garry [this message]
2024-11-07 18:27 ` Jens Axboe
2024-11-07 19:54 ` John Garry
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=e0a82859-6c9e-43d4-b6ee-4b96fa193fa9@oracle.com \
--to=john.g.garry@oracle.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=song@kernel.org \
--cc=yukuai3@huawei.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