Messages in this thread | | | Subject | Re: [PATCH -mm v2 1/3] mm/oom_kill: remove the wrong fatal_signal_pending() check in oom_kill_process() | From | Tetsuo Handa <> | Date | Fri, 2 Oct 2015 23:36:47 +0900 |
| |
Oleg Nesterov wrote: > Tetsuo, sorry, I don't understand your question... > > > because it is possible that T starts the coredump, T sends SIGKILL to P, > > P calls out_of_memory() on GFP_FS allocation, > > yes, and since fatal_signal_pending() == T we do not even check > task_will_free_mem(). > > > P misses to set SIGKILL on T? > > > > Since T sends SIGKILL to all clone(CLONE_VM) tasks upon coredump, P needs > > to do > > > > [...snip...] > > > after mark_oom_victim(current) in case T is not in the same thread group? > > I do not see how this depends on "not in the same thread group". This > fatal_signal_pending() doesn't look right in any case.
You already answered my question. ;-) You confirmed this is a possible silent hang up path (I mean, hang up without OOM killer messages).
> > If yes, what happens if some task failed to receive SIGKILL due to > > p->signal->oom_score_adj == OOM_SCORE_ADJ_MIN condition? > > Oh. This is another issue. I already tried to suggest to remove this > check. But this needs more discussion, hopefully we can do this later.
OK.
| |