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,
John Garry <john.g.garry@oracle.com>
Subject: [PATCH v2 0/7] bio_split() error handling rework
Date: Mon, 28 Oct 2024 15:27:23 +0000 [thread overview]
Message-ID: <20241028152730.3377030-1-john.g.garry@oracle.com> (raw)
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/21f19b4b-4b83-4ca2-a93b-0a433741fd26@oracle.com/
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 f1be1788a32e (block/for-6.13/block) block: model freeze & enter
queue as lock for supporting lockdep
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 (7):
block: Use BLK_STS_OK in bio_init()
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 | 16 +++++++++----
block/blk-crypto-fallback.c | 2 +-
block/blk-merge.c | 15 ++++++++----
drivers/md/raid0.c | 12 ++++++++++
drivers/md/raid1.c | 32 +++++++++++++++++++++++--
drivers/md/raid10.c | 47 ++++++++++++++++++++++++++++++++++++-
6 files changed, 110 insertions(+), 14 deletions(-)
--
2.31.1
next reply other threads:[~2024-10-28 15:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 15:27 John Garry [this message]
2024-10-28 15:27 ` [PATCH v2 1/7] block: Use BLK_STS_OK in bio_init() John Garry
2024-10-28 16:11 ` Christoph Hellwig
2024-10-28 16:32 ` John Garry
2024-10-28 15:27 ` [PATCH v2 2/7] block: Rework bio_split() return value John Garry
2024-10-28 16:12 ` Christoph Hellwig
2024-10-29 9:12 ` Johannes Thumshirn
2024-10-28 15:27 ` [PATCH v2 3/7] block: Error an attempt to split an atomic write in bio_split() John Garry
2024-10-28 16:12 ` Christoph Hellwig
2024-10-29 9:12 ` Johannes Thumshirn
2024-10-28 15:27 ` [PATCH v2 4/7] block: Handle bio_split() errors in bio_submit_split() John Garry
2024-10-28 16:12 ` Christoph Hellwig
2024-10-29 9:13 ` Johannes Thumshirn
2024-10-28 15:27 ` [PATCH v2 5/7] md/raid0: Handle bio_split() errors John Garry
2024-10-29 3:52 ` Yu Kuai
2024-10-28 15:27 ` [PATCH v2 6/7] md/raid1: " John Garry
2024-10-29 3:48 ` Yu Kuai
2024-10-29 8:45 ` John Garry
2024-10-29 11:30 ` Yu Kuai
2024-10-29 11:36 ` John Garry
2024-10-29 11:32 ` Yu Kuai
2024-10-29 12:12 ` Yu Kuai
2024-10-29 12:21 ` John Garry
2024-10-28 15:27 ` [PATCH v2 7/7] md/raid10: " John Garry
2024-10-29 11:55 ` Yu Kuai
2024-10-29 12:05 ` John Garry
2024-10-29 12:10 ` Yu Kuai
2024-10-29 9:11 ` [PATCH] btrfs: handle bio_split() error Johannes Thumshirn
2024-10-29 10:33 ` John Garry
2024-10-30 14:00 ` kernel test robot
2024-10-30 14:06 ` Johannes Thumshirn
2024-10-30 14:20 ` John Garry
2024-10-30 14:29 ` Johannes Thumshirn
2024-10-30 20:05 ` Dan Carpenter
2024-10-31 9:29 ` 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=20241028152730.3377030-1-john.g.garry@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
all inboxes | Powered by JetHome®