On Sun 31-05-15 20:10:23, Tetsuo Handa wrote: [...] > By the way, I got two mumbles. > > Is "If any of p's children has a different mm and is eligible for kill," logic > in oom_kill_process() really needed? Didn't select_bad_process() which was > called proior to calling oom_kill_process() already choose a best victim > using for_each_process_thread() ? This tries to have smaller effect on the system. It tries to kill younger tasks because this might be and quite often is sufficient to resolve the OOM condition. > Is "/* mm cannot safely be dereferenced after task_unlock(victim) */" true? > It seems to me that it should be "/* mm cannot safely be compared after > task_unlock(victim) */" because it is theoretically possible to have > > CPU 0 CPU 1 CPU 2 > task_unlock(victim); > victim exits and releases mm. > Usage count of the mm becomes 0 and thus released. > New mm is allocated and assigned to some thread. > (p->mm == mm) matches the recreated mm and kill unrelated p. > > sequence. We need to either get a reference to victim's mm before > task_unlock(victim) or do comparison before task_unlock(victim). Hmm, I guess you are right. The race is theoretically possible, especially when there are many tasks when iterating over the list might take some time. reference to the mm would solve this. Care to send a patch? -- 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>