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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>