We faced a crash on printing the information about the OOM timeout because of a stale pointer in ctx->victim, looks like mark_oom_victim() and oom_unlock() were called for a process already in do_exit() after exit_oom_victim() call.
We have fixed the race, but as this message is not so useful, lets remove it as well. Just in case. Even in case we have not fully fix the race and we ever have a stale ctx->victim and which means we miss the OOM context release, the worst scenario leads to a process in __wait_oom_context() waits for 5 secs. https://jira.sw.ru/browse/PSBM-143283 Signed-off-by: Denis Lunev <d...@virtuozzo.com> Signed-off-by: Konstantin Khorenko <khore...@virtuozzo.com> --- mm/oom_kill.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 74beb3a03335..217c04f08a47 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -576,22 +576,16 @@ bool oom_trylock(struct mem_cgroup *memcg) return false; } else if (ctx->owner || ctx->victim) { /* - * Timeout. Release the context and dump stack - * trace of the stuck process. + * Timeout. Release the context. * - * To avoid dumping stack trace of the same task - * more than once, we mark the context that - * contained the victim when it was killed (see - * mark_oom_victim). + * Here was a stack trace of the stuck process, but it + * has been removed because: + * + * 1. We had a crash here due to stale ctx->victim, we + * have fixed that, but as a burnt child we dread + * the fire. + * 2. The stack trace here is not useful anyway. */ - struct task_struct *p = ctx->victim; - - if (p && ctx->marked) { - pr_err("OOM kill timeout: %d (%s)\n", - task_pid_nr(p), p->comm); - show_stack(p, NULL); - } - __release_oom_context(ctx); } } while ((iter = mem_cgroup_iter(memcg, iter, NULL))); -- 2.24.3 _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
