On Thu, Feb 08, 2024 at 08:55:05PM +0100, Vlastimil Babka (SUSE) wrote: > - NOWAIT - as said already, we need to make sure we're not turning an > allocation that relied on too-small-to-fail into a null pointer exception or > BUG_ON(!page). It's probably not feasible to audit everything that can be > called underneath when adding a new scoped NOWAIT. Static analysis probably > won't be powerful enough as well. Kent suggested fault injection [1]. We > have the framework for a system-wide one but I don't know if anyone is > running it and how successful it is. I've also got a better fault injection library in the pipeline - I'll be posting it after memory allocation profiling is merged, since that has the library code needed for the new fault injection. The new stuff gives us (via the same hooks for memory allocation profiling), per callsite individually controllable injection points - which means it's way easier to inject memory allocation failures into existing tests and write tests that cover a specific codepath. e.g. what I used to do with this code was flip on random memory allocation failures for all code in fs/bcachefs/ after mounting, and I had every test doing that (at one point in time, bcachefs could handle _any_ allocation failure after startup without reporting an error to userspace, but sadly not quite anymore). that, plus code coverage analysis should make this pretty tractable.
