[PATCH 0/2] revert unconditional slab and page allocator fault injection calls

[Vlastimil Babka <vbabka@suse.cz>]

These two patches largely revert commits that added function call
overhead into slab and page allocation hotpaths and that cannot be
currently disabled even though related CONFIG_ options do exist.

A much more involved solution that can keep the callsites always
existing but hidden behind a static key if unused, is possible [1] and
can be pursued by anyone who believes it's necessary. Meanwhile the fact
the should_failslab() error injection is already not functional on
kernels built with current gcc without anyone noticing [2], and lukewarm
response to [1] suggests the need is not there. I believe it will be
more fair to have the state after this series as a baseline for possible
further optimisation, instead of the unconditional overhead.

For example a possible compromise for anyone who's fine with an empty
function call overhead but not the full CONFIG_FAILSLAB /
CONFIG_FAIL_PAGE_ALLOC overhead is to reuse patch 1 from [1] but insert
a static key check only inside should_failslab() and
should_fail_alloc_page() before performing the more expensive checks.

[1] https://lore.kernel.org/all/20240620-fault-injection-statickeys-v2-0-e23947d3d84b@suse.cz/#t
[2] https://github.com/bpftrace/bpftrace/issues/3258

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
Vlastimil Babka (2):
      mm, slab: put should_failslab() back behind CONFIG_SHOULD_FAILSLAB
      mm, page_alloc: put should_fail_alloc_page() back behing CONFIG_FAIL_PAGE_ALLOC

 include/linux/fault-inject.h | 11 ++++-------
 kernel/bpf/verifier.c        |  4 ++++
 mm/fail_page_alloc.c         |  4 +++-
 mm/failslab.c                | 14 ++++++++------
 mm/page_alloc.c              |  6 ------
 mm/slub.c                    |  8 --------
 6 files changed, 19 insertions(+), 28 deletions(-)
---
base-commit: 256abd8e550ce977b728be79a74e1729438b4948
change-id: 20240711-b4-fault-injection-reverts-e4d099e620f5

Best regards,
-- 
Vlastimil Babka <vbabka@suse.cz>