| Message ID | 0828a149-786e-7c06-b70a-52d086818ea3@virtuozzo.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | memcg: prohibit unconditional exceeding the limit of dying tasks | expand |
On Sat 23-10-21 16:19:28, Vasily Averin wrote: > Any allocation failure during the #PF path will return with VM_FAULT_OOM > which in turn results in pagefault_out_of_memory which in own turn > executes out_out_memory() and can kill a random task. > > An allocation might fail when the current task is the oom victim > and there are no memory reserves left. The OOM killer is already > handled at the page allocator level for the global OOM and at the > charging level for the memcg one. Both have much more information > about the scope of allocation/charge request. This means that > either the OOM killer has been invoked properly and didn't lead > to the allocation success or it has been skipped because it couldn't > have been invoked. In both cases triggering it from here is pointless > and even harmful. > > It makes much more sense to let the killed task die rather than to > wake up an eternally hungry oom-killer and send him to choose a fatter > victim for breakfast. > > Suggested-by: Michal Hocko <mhocko@suse.com> > Signed-off-by: Vasily Averin <vvs@virtuozzo.com> Acked-by: Michal Hocko <mhocko@suse.com> Thanks! > --- > mm/oom_kill.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 831340e7ad8b..1deef8c7a71b 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -1137,6 +1137,9 @@ void pagefault_out_of_memory(void) > if (mem_cgroup_oom_synchronize(true)) > return; > > + if (fatal_signal_pending(current)) > + return; > + > if (!mutex_trylock(&oom_lock)) > return; > out_of_memory(&oc); > -- > 2.32.0
diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 831340e7ad8b..1deef8c7a71b 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -1137,6 +1137,9 @@ void pagefault_out_of_memory(void) if (mem_cgroup_oom_synchronize(true)) return; + if (fatal_signal_pending(current)) + return; + if (!mutex_trylock(&oom_lock)) return; out_of_memory(&oc);
Any allocation failure during the #PF path will return with VM_FAULT_OOM which in turn results in pagefault_out_of_memory which in own turn executes out_out_memory() and can kill a random task. An allocation might fail when the current task is the oom victim and there are no memory reserves left. The OOM killer is already handled at the page allocator level for the global OOM and at the charging level for the memcg one. Both have much more information about the scope of allocation/charge request. This means that either the OOM killer has been invoked properly and didn't lead to the allocation success or it has been skipped because it couldn't have been invoked. In both cases triggering it from here is pointless and even harmful. It makes much more sense to let the killed task die rather than to wake up an eternally hungry oom-killer and send him to choose a fatter victim for breakfast. Suggested-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Vasily Averin <vvs@virtuozzo.com> --- mm/oom_kill.c | 3 +++ 1 file changed, 3 insertions(+)