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@xxxxxxxx> > Signed-off-by: Vasily Averin <vvs@xxxxxxxxxxxxx> Acked-by: Michal Hocko <mhocko@xxxxxxxx> 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 -- Michal Hocko SUSE Labs
