Michal Hocko wrote: > On Tue 23-12-14 22:00:52, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > > and finally sets SIGKILL on that victim thread. If such a delay > > > > happened, that victim thread is free to abuse TIF_MEMDIE for that period. > > > > Thus, I thought sending SIGKILL followed by setting TIF_MEMDIE is better. > > > > > > I don't know, I can hardly find a scenario where it would make any > > > difference in the real life. If the victim needs to allocate a memory to > > > finish then it would trigger OOM again and have to wait/loop until this > > > OOM killer releases the oom zonelist lock just to find out it already > > > has TIF_MEMDIE set and can dive into memory reserves. Which way is more > > > correct is a question but I wouldn't change it without having a really > > > good reason. This whole code is subtle already, let's not make it even > > > more so. > > > > gfp_to_alloc_flags() in mm/page_alloc.c sets ALLOC_NO_WATERMARKS if > > the victim task has TIF_MEMDIE flag, doesn't it? > > This is the whole point of TIF_MEMDIE. > > [...] > > > 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. Why the victim has to die before receiving SIGKILL? The victim can access memory reserves until SIGKILL is delivered, can't it? -- 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>