mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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..


  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®