On Tue 23-12-14 22:20:57, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Tue 23-12-14 22:00:52, Tetsuo Handa wrote: [...] > > > Then, I think deferring SIGKILL might widen race window for abusing TIF_MEMDIE. > > > > How would it abuse the flag? The OOM victim has to die and if it needs > > to allocate then we have to allow it to do so otherwise the whole > > exercise was pointless. fatal_signal_pending check is not so widespread > > in the kernel that the task would notice it immediately. > > 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. > Why the victim has to die before receiving SIGKILL? It has to die to resolve the current OOM condition. I haven't written anything about dying before receiving SIGKILL. > The victim can access memory reserves until SIGKILL is delivered, > can't it? And why does that matter? It would have to do such an allocation anyway because it wouldn't proceed without it... And the only difference between having the flag and not having it is that the allocation has higher chance to succeed with the flag so it will not trigger the OOM killer again right away. See the point or am I missing something here? -- Michal Hocko SUSE Labs -- 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>