[Devel] [PATCH rh7 2/2] oom: Drop the OOM timeout message

[Konstantin Khorenko]

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 <den at virtuozzo.com>
Signed-off-by: Konstantin Khorenko <khorenko at 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