Re: configurable block error injection

[Christoph Hellwig <hch@lst.de>]

On Thu, Jun 04, 2026 at 01:06:13PM +0200, Daniel Gomez wrote:
> IIU the series correctly, and oversimplifying: when
> injection is enabled and a bio matches, the block layer completes the
> bio inline with the chosen blk_status_t (the status= rule from debugfs)
> via bio_endio_status(). The submission path returns to the caller
> immediately, with the bio already in the error state. Nothing is ever
> sent to the device, but the completion path sees the injected error.

Yes.

> > I'd have to allow access to certain bio
> 
> With struct_ops the bio is passed to the ebpf side as read-only, bio 
> fields can be read to decide the policy but cannot write them. Is 
> read-only access to bio fields itself a concern?

Yes, for the reason state below.

> 
> > fields and would have create a stable UAPI for commands and status
> > using the fake BTF struct access which really would not be a good
> > idea here as we need to be able to change internals.  
> 
> That should not be a problem at all. With CO-RE (compile once, run
> everywhere) the program resolves the bio field offsets against the
> BTF of the kernel it loads on, so it adapts dynamically if the layout
> changes. The contract is just the struct_ops callback signature: a
> struct bio * argument and a blk_status_t return. And that doesn't imply
> any UAPI commitment AFAIK.

That assumes the fields even exists in this form.  And we definitively
need to do things about the iter going ahead.  In other words we have
to build up a huge abstraction here first.

> > Additionally
> > having fully BTF-enabled toolchains in test VMs is not great either.
> 
> Are you referring to the old BCC toolchain requirements [1]? This is
> solved in CO-RE [2]. The toolchain (Clang/LLVM, pahole) stays on the
> build host; the test VM only needs the prebuilt BPF object, libbpf at
> runtime, and the kernel's own BTF (CONFIG_DEBUG_INFO_BTF). No compiler
> or BTF toolchain is required inside the VM. Clang/LLVM 10+ is enough to
> build CO-RE libbpf tools [3].

libbpf and BTF support is what I mean.  And of course whatever code
you write to communicate with it as a simple shell script won't work
any more.

> Are you referring to the bio sector range comparison in
> __blk_error_inject()?

Yes.

> I don't think that needs to be delegated to a
> BPF map (Documentation/bpf/maps.rst). The ebpf side has direct access
> to the bio fields, so it can apply the same sector/op filtering
> __blk_error_inject() does today. That match is already a linear list
> walk, so the ebpf program just runs the same [start, end] condition
> check.

Which means I need to write eBPF code for every specific range I
want to inject, which makes the thing very hard to use.

> In summary: what do you think of evolving this series
> into eBPF, but BPF_PROG_TYPE_STRUCT_OPS instead of
> ALLOW_ERROR_INJECTION/bpf_override_return()?.

As said before, I prototyped it and it was a mess.  Having about 300
lines of simple code that can be directly used from a shell script
seems much preferable.