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

Petr Vorel <[email protected]>
Newsgroups gmane.linux.ltp
Message-ID <20260811044507.GA230862@pevik>
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-IBi9RG/[email protected]/

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 <[email protected]>

> This email address is no longer in use :).

+1

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.