<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2020 at 8:40 PM Martin Doucha <<a href="mailto:mdoucha@suse.cz">mdoucha@suse.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/31/20 10:37 AM, Jan Stancek wrote:<br>
> ----- Original Message ----<br>
>> It sounds more like the OOM-Killer defect but not fork12.<br>
> <br>
> Badness score is based on proportion of rss/swap. It doesn't seem<br>
> like defect to me, we just quickly spawn many small tasks.<br>
<br>
Yes, OOM killer is working as intended here. fork12 is basically a fork<br>
bomb test so it spawns thousands of processes with almost no allocated<br>
memory. Since kernel 2.6.36, OOM killer uses only two criteria to decide<br>
which process to kill:<br>
- how much memory/swap it has allocated<br>
- whether the process is privileged<br>
<br>
Since fork12 children have low memory footprint, most system processes<br>
look like better targets for OOM killer right now. But we're not testing<br>
userspace resilience against fork bomb here. We're trying to crash the<br>
kernel itself.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Sounds reasonable to me, thanks!</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>> What we do for that is to protect the parent shell and its harness<br>
>> to avoid oom_kill_process() acting on them.<br>
>> <br>
>> On the other side, if we do raise the oom score of fork12, that<br>
>> would not guarantee OOM-Killer do right evaluation but just makes<br>
>> fork12 easily to be killed in testing.<br>
> <br>
> fork12 is not an OOM test, so I don't see problem with this. We only<br>
> need OOM to kill something we don't care about, in case it triggers.<br>
> <br>
> I'd move oom_score_adj after fork, so only child processes are better<br>
> target, not the parent.<br>
<br>
oom_score_adj is inherited by child processes and OOM killer tries to<br>
kill first-level children if it can. So setting oom_score_adj on the<br>
main fork12 process will work exactly the way we want - OOM killer will<br>
kill one of the child processes, fork12 will notice on line 80 and exit<br>
gracefully.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Theoretically yes! Isn't it makes the main fork12 more robust if not set high score to it?<br></div></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There could be problems only on kernels older than 2.6.36 where the<br>
number of forked children was included in OOM score calculation and the<br>
main worker process might get targeted directly (not sure if the<br>
kill-children-first approach was used back then).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It sounds a little tricky. The method I can think of now is to reset the max process limitation for the lower memory system, to make the test includes fork bomb but NOT costs too much resource in fork12?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Either way, trying to protect the parent shell is a bad idea. We'd have<br>
to set negative oom_score_adj on it and if fork12 crashes before it can<br>
reset it back to zero, all further test processes would inherit the OOM<br>
protection.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">My bad! The way we have tried is to set a negative score for the test harness and LTP related process, then reset parent shell score to 0, which avoids other tests inherit OOM protection from the shell.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>