When trying to exhaust system memory in order to exercise LMEM eviction
under OOM conditions, a gem_leak helper process may itself become a victim
of memory shortage. If our i915 TTM VM fault handler fails to allocate a
page and responds with a SIGBUS signal when the helper process is trying
to store data in a mmaped i915 GEM object with memset then the process
crashes. Unfortunately, such crash is not only reported on stdout, strerr
and dmesg as premature, additional result from the subtest while it is
still in progress, but also renders the final result as failed.
Since page allocation failures are unavoidable under OOM conditions, and
the SIGBUS signal response from our TTM fault handler is correct in such
cases, catch those signals and let the helper process continue.
While being at it, improve concurrency of smem-oom helpers and be more
clear about their supplementary role.
v2: Add 2 introductory patches that make the code more predictable and
clear,
- add a comment about no need to restore default SIGBUS handler (Kamil),
- fix missing initialization of sa.sa_mask with sigemptyset().
Cc: Kamil Konieczny <[email protected]>
Janusz Krzysztofik (3):
tests/gem_lmem_swapping: Improve concurrency of smem-oom helpers.
tests/intel/gem_lmem_swapping: Be more clear about subprocesses role
tests/intel/gem_lmem_swapping: Expect gem leak helper crashes
tests/intel/gem_lmem_swapping.c | 60 +++++++++++++++++++++++++--------
1 file changed, 46 insertions(+), 14 deletions(-)
--
2.53.0
