On 02/06/2026 07.45, Christoph Hellwig wrote: > Hi all, > > this series adds a new configurable block error injection facility. > We already have a few to inject block errors, but unfortunately most > of them are either not very useful or hard to use, or both: > > - The fail_make_request failure injection point can't distinguish > different commands, different ranges in the file and can only injection > plain I/O errors. > - the should_fail_bio 'dynamic' failure injection has all the same issues > as fail_make_request > - dm-error can only fail all command in the table using BLK_STS_IOERR > and requires setting up a new block device > - dm-flakey and dm-dust allow all kinds of configurability, but still > don't have good error selection, no good support for non-read/write > commands and are limited to the dm table alignment requirements, > which for zoned devices enforces setting them up for an entire zone. > They also once again require setting up a stacked block device, > which is really annoying in harnesses like xfstests > > This series adds a new debugfs-based block layer error injection > that allows to configure what operations and ranges the injection > applied to, and what status to return. It also allows to configure a > failure ratio similar to the xfs errortag injection.
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 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. A previous attempt to add inline error injection [2] was rejected as too intrusive / source-polluting; the eBPF approach solves that, since the injection logic lives in a standalone tool/script rather than in the kernel sources. What do you guys think? [1] https://lpc.events/event/19/contributions/2204/ [2] https://lore.kernel.org/all/[email protected]/
