From: Christoph Hellwig <hch@lst.de>
To: Md Haris Iqbal <haris.iqbal@linux.dev>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org
Subject: Re: [v3 for-next 2/3] block: allow error injection rules to delay bios
Date: Mon, 5 Oct 2026 10:56:13 +0200 [thread overview]
Message-ID: <20261005085613.GB9160@lst.de> (raw)
In-Reply-To: <20260928221634.43239-3-haris.iqbal@linux.dev>
On Tue, Sep 29, 2026 at 12:16:33AM +0200, Md Haris Iqbal wrote:
> +static void blk_error_inject_delay_work(struct work_struct *work)
> +{
> + struct blk_error_inject_delay *d = container_of(to_delayed_work(work),
> + struct blk_error_inject_delay, dwork);
> + struct bio *bio = d->bio;
> + struct gendisk *disk = bio->bi_bdev->bd_disk;
> + blk_status_t status = d->status;
> +
> + kfree(d);
> +
> + if (status != BLK_STS_OK) {
> + pr_info_ratelimited("%pg: injecting %s error for %s at sector %llu:%u\n",
> + disk->part0, blk_status_to_str(status),
> + blk_op_str(bio_op(bio)), bio->bi_iter.bi_sector,
> + bio_sectors(bio));
> + bio->bi_status = status;
> + bio_endio(bio);
This duplicates the tail of __blk_error_inject, please share the code.
> + } else {
And return after this to keep the other path straight line.
> +/*
> + * Hand the bio to a workqueue that submits or fails it once the delay has
> + * expired. Both blk_mq_submit_bio() and ->submit_bio can sleep, so this can't
> + * be completed from the timer itself.
> + *
> + * Returns false if the bio can't be delayed, in which case the caller handles
> + * it immediately instead.
> + */
I'd drop the comment, it just states what is obvious from the code
below.
> +static bool blk_error_inject_delay(struct gendisk *disk, struct bio *bio,
> + blk_status_t status, unsigned int delay_us)
> +{
> + struct blk_error_inject_delay *d;
> +
> + /* never block a bio that asked not to be blocked */
> + if (bio->bi_opf & REQ_NOWAIT)
> + return false;
We should probably complete it with BLK_STS_AGAIN as we would do
for a real delay?
> +
> + d = kmalloc_obj(*d, GFP_NOIO);
> + if (!d)
> + return false;
Should we log a warning that the intended delay did not happen?
> + /*
> + * Mark the bio before queueing the work, which can complete it as soon
> + * as it is queued. Splitting happens below the injection hook, but
> + * bio_submit_split_bioset() resubmits the remainder through the hook
> + * again, and as bio_split() only advances the original bio that
> + * remainder still matches the same rule. Without this a bio would be
> + * delayed once per split.
> + */
Over-eager comment. But we should probably also set the flag for
non-delayed bios anyway and do it as soon as any rule matches?
> +static int __init blk_error_injection_init_wq(void)
> +{
> + /*
> + * WQ_MEM_RECLAIM so that a delayed bio on the reclaim path can still
> + * find a worker under memory pressure. Note that this only guarantees
> + * a worker exists, not that it is free: submitting a bio can block on
> + * a queue freeze or on tag allocation, so a delayed bio can still be
> + * held up behind another one.
> + */
Very long comment explaining the obvious, everything doing I/O needs
WQ_MEM_RECLAIM. Please drop it.
> + blk_error_inject_wq = alloc_workqueue("blk_error_inject", WQ_MEM_RECLAIM | WQ_UNBOUND, 0);
Overly long line.
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index 98e21b4cbf32..50e28dc0f1f9 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -323,6 +323,7 @@ enum {
> BIO_ZONE_WRITE_PLUGGING, /* bio handled through zone write plugging */
> BIO_EMULATES_ZONE_APPEND, /* bio emulates a zone append operation */
> BIO_COMPLETE_IN_TASK, /* complete bi_end_io() in task context */
> + BIO_ERROR_INJECTED, /* error injection rules already applied */
> BIO_FLAG_LAST
> };
With this we've used up the last BIO_ flag. I hope this won't
cause problems in the future..
next prev parent reply other threads:[~2026-10-05 8:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 22:16 [v3 for-next 0/3] block: delay support for error injection Md Haris Iqbal
2026-09-28 22:16 ` [v3 for-next 1/3] block: Reject unknown status tags in error injection rules Md Haris Iqbal
2026-10-05 8:49 ` Christoph Hellwig
2026-09-28 22:16 ` [v3 for-next 2/3] block: allow error injection rules to delay bios Md Haris Iqbal
2026-10-05 8:56 ` Christoph Hellwig [this message]
2026-09-28 22:16 ` [v3 for-next 3/3] Documentation: block: document error injection delay feature Md Haris Iqbal
2026-10-05 8:56 ` Christoph Hellwig
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=20261005085613.GB9160@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=haris.iqbal@linux.dev \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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®