Re: configurable block error injection

[Christoph Hellwig <hch@lst.de>]

On Tue, Jun 02, 2026 at 11:58:25AM +0200, Daniel Gomez wrote:
> I wonder if the block layer would be interested in moving block error
> injection off the should_fail() fault injection framework and extending
> the ALLOW_ERROR_INJECTION annotation instead and offloading all the
> debugfs configuration logic (block/error-injection.c) into eBPF?

I've looked into plain ALLOW_ERROR_INJECTION-based injection and it
is not very useful.  I didn't even now eBPF could use it, but I
looked into other eBPF injections and at least for my uses cases
it was a bit of a mess.  I'd have to allow access to certain bio
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.  Additionally
having fully BTF-enabled toolchains in test VMs is not great either.

I've also not actually found any good map type for range lookups,
which is kinda essential here.

> I talked about moderr [1] at LPC 2025. It's a simple error injection
> tool in eBPF for the module subsystem. The suggested direction there was
> to generalize the tool to ideally to no tool at all, and leverage
> bpftrace to describe the error injection conditions a given
> subsystem needs to be tested under. That would let blktests, for
> example, absorb that and simplify the configuration logic this series
> adds in the kernel for debugfs.

I don't think pulling in ebpftrace for simple error injection is a
winning proposition..

> 
> A previous attempt to add inline error injection [2] was rejected as too
> intrusive / source-polluting;

I'm not sure a single hand waivy comment counts as rejection, although
I'm not a huge fan of setup_fault_attr - it makes a mess of debugfs and
creates a lot of boilerplate for a single not very much configurable call
site.  That might be ok for something like the make_request case
(although I think we can do better as shown in this patch), but for
making random functions fail it is a lot of overhead.  These injections
points also are not anywhere near stable enough to be exposed.