Re: [LTP] [PATCH v4] shell: enable OOM protection by default

[Petr Vorel <pvorel@suse.cz>]

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp