Re: [RFC PATCH] oom: Don't count on mm-less current process.

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Michal Hocko wrote:
> On Tue 23-12-14 22:20:57, Tetsuo Handa wrote:
> > I'm talking about possible delay between TIF_MEMDIE was set on the victim
> > and SIGKILL is delivered to the victim.
> 
> I can read what you wrote. You are just ignoring my questions it seems
> because I haven't got any reason _why it matters_. My point was that the
> victim might be looping in the kernel and doing other allocations until
> it notices it has fatal_signal_pending and bail out. So the delay
> between setting the flag and sending the signal is not that important
> AFAICS.

My point is that the victim might not be looping in the kernel
when getting TIF_MEMDIE.

Situation:

  P1: A process who called the OOM killer
  P2: A process who is chosen by the OOM killer

  P2 is running a program shown below.
----------
int main(int argc, char *argv[])
{
	const int fd = open("/dev/zero", O_RDONLY);
	char *buf = malloc(1024 * 1048576);
	if (fd == -1 || !buf)
		return 1;
	memset(buf, 0, 512 * 1048576);
	sleep(10);
	read(fd, buf, 1024 * 1048576);
	return 0;
}
----------

Sequence:

  (1) P2 is sleeping at sleep(10).
  (2) P1 triggers the OOM killer and P2 is chosen.
  (3) The OOM killer sets TIF_MEMDIE on P2.
  (4) P2 wakes up as sleep(10) expired.
  (5) P2 calls read().
  (6) P2 triggers page fault inside read().
  (7) P2 allocates from memory reserves for handling page fault.
  (8) The OOM killer sends SIGKILL to P2.
  (9) P2 receives SIGKILL after all memory reserves were
      allocated for handling page fault.
  (10) P2 starts steps for die, but memory reserves may be
       already empty.

My worry:

  More the delay between (3) and (8) becomes longer (e.g. 30 seconds
  for an overdone case), more likely to cause memory reserves being
  consumed before (9). If (3) and (8) are reversed, P2 will notice
  fatal_signal_pending() and bail out before allocating a lot of
  memory from memory reserves.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>