[LTP] [PATCH v4] shell: enable OOM protection by default
Petr Vorel
pvorel@suse.cz
Tue Aug 11 06:45:07 CEST 2026
Hi Li, Andrea,
> Hi Andrea, Petr,
> After looking into it more, now I slightly think doing OOM protection
> in the shell harness isn't worth it: the benefit doesn't justify the
> complexity. Forking the whole test body means dealing with cleanup and
> timer ownership across the fork, plus passing results back from the
> child, and all of that would need revalidating for every shell test
> that goes through tst_test.sh.
+1
> Given that only a few tests actually produce memory pressure, I'd
> rather keep it simple and handle it locally in those tests instead of
> touching the common harness. Something like a small helper the test
> can wrap the memory hungry workload with:
> tst_oom_run()
> {
> ( echo 0 > /proc/self/oom_score_adj; exec "$@" )
> }
+1
Maybe test should declare through TST_* variable that it needs OOM killer
(approach on Andrea's v2 [1]). I'm sorry Andrea, it takes time to find a right
solution.
[1] https://lore.kernel.org/ltp/20260730-shell_oom_protection-v2-0-be1de2baa83d@suse.com/
And again, IMHO the real solution would be to rewrite tests into C API or shell
loader API.
> The harness (or the setup) protects itself with oom_score_adj -1000,
> and only the workload started via tst_oom_run stays killable.
> This keeps the harness alive to report results without forking the
> whole test body, and matches the C harness model where the worker is
> the unprotected part.
Yes, forking (the subshell) part looked to me fragile.
> Does this direction make sense to you, or do you see a case that
> really needs the protection to be harness-wide?
> > Suggested-by: Li Wang <liwang@redhat.com>
> This email address is no longer in use :).
+1
Kind regards,
Petr
More information about the ltp
mailing list