On Tue, Dec 14, 2021 at 12:15 AM Cyril Hrubis <chrubis@suse.cz> wrote:

> Protecting the test harness is a bad idea because oom_score_adj is
> inherited by child processes and it'll affect other tests as well. Given
> the nature of OOM tests, I'd rather not assume that the protection will
> be properly removed at the end.

This should be easily doable since the test library forks right before
it executes the test, so we have a single place where the score has to
be reset.

I think so. And we can even export the function as global to

make it easy to enable/cancel the OOM protection for any

process at any time we wanted. Then, just resetting the child

process oom_score_adj to 0 can avoid to inherited from the

lib-process score as well.

e.g.

void tst_enable_oom_protection(pid_t pid)

void tst_cancel_oom_protection(pid_t pid)

For new library tests there is a process that does nothing but waits for
the actuall test pid to finish and kills it on timeout. It really makes
sense to protect this exact process and maybe even mlock() it into the
memory.

Regards,

Li Wang