Error injection can only fail a bio today.  This adds a delay_us option so
that a rule can hold a bio back first, to model a slow device.

The delay happens above the driver, so it is invisible to the I/O
statistics and never reaches the blk-mq timeout handler or SCSI error
handling.  What it does exercise is the code waiting above the block
layer: io_uring cancellation, hung task detection, and filesystem or
userspace timeouts.

Two things are worth a look.  A delayed bio is resubmitted below the
injection hook, so the rules are not applied to it again and it can never
pick up a status from another rule.  And holding a bio back reorders it
against bios submitted later, which breaks sequential write ordering on
zoned devices.  Both are documented in patch 3.

Patch 1 is a prep cleanup.  It moves the rejection of an unknown status
tag into the parser, because patch 2 makes a rule without a status valid.

Tested in a VM.

Md Haris Iqbal (3):
  block: reject unknown status tags in error injection rules
  block: allow error injection rules to delay bios
  Documentation: block: document error injection delays

 Documentation/block/error-injection.rst |  56 ++++++++-
 block/blk-core.c                        |  13 +-
 block/blk.h                             |   1 +
 block/error-injection.c                 | 154 +++++++++++++++++++++---
 4 files changed, 201 insertions(+), 23 deletions(-)

-- 
2.53.0

On Thu, Aug 27, 2026 at 02:01:12AM +0200, Md Haris Iqbal wrote:
> Two things are worth a look.  A delayed bio is resubmitted below the
> injection hook, so the rules are not applied to it again and it can never
> pick up a status from another rule.  And holding a bio back reorders it
> against bios submitted later, which breaks sequential write ordering on
> zoned devices.  Both are documented in patch 3.

Would it be possible to do the delay on the completion side instead?
That should avoid those submission order problems.

On 8/27/26 05:49, Keith Busch wrote:
> On Thu, Aug 27, 2026 at 02:01:12AM +0200, Md Haris Iqbal wrote:
>> Two things are worth a look.  A delayed bio is resubmitted below the
>> injection hook, so the rules are not applied to it again and it can never
>> pick up a status from another rule.  And holding a bio back reorders it
>> against bios submitted later, which breaks sequential write ordering on
>> zoned devices.  Both are documented in patch 3.
> 
> Would it be possible to do the delay on the completion side instead?
> That should avoid those submission order problems.

Seems not. At bio_endio, bi_size is 0 hence the comparison rule cannot 
be calculated. What can be done is to capture the decision to delay or 
not at submit, and then execute it at completion, but something (the 
same kmalloc_obj?) needs to carry this all the way.

Besides, the bio would have been written to the device already, meaning 
if the rule said to delay and then fail, the upper layer will see the 
failure, but the data would have landed in the disk. Maybe not the worst 
idea, but still semantically incorrect since the documentation claims 
that nothing is seen by the device.

One way would be to omit delay injection for all bios meant for zoned 
block devices.