Re: WARNING in try_charge

From: Michal Hocko
Date: Mon Aug 06 2018 - 14:40:04 EST


On Mon 06-08-18 20:13:39, Michal Hocko wrote:
> I simply do not see how this is possible. Let's try with the following
> extended debugging patch.
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 116b181bb646afedd770985de20a68721bdb2648
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 4603ad75c9a9..e2dfdf4361ba 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1388,6 +1388,8 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask,
> bool ret;
>
> mutex_lock(&oom_lock);
> + pr_info("task=%s pid=%d invoked memcg oom killer. oom_victim=%d\n",
> + current->comm, current->pid, tsk_is_oom_victim(current));
> ret = out_of_memory(&oc);
> mutex_unlock(&oom_lock);
> return ret;
> @@ -2108,6 +2110,9 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
>
> if (mem_cgroup_is_root(memcg))
> return 0;
> + if (tsk_is_oom_victim(current))
> + pr_info("task=%s pid=%d charge for nr_pages=%d\n",
> + current->comm, current->pid, nr_pages);
> retry:
> if (consume_stock(memcg, nr_pages))
> return 0;
> @@ -2137,8 +2142,11 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> */
> if (unlikely(tsk_is_oom_victim(current) ||
> fatal_signal_pending(current) ||
> - current->flags & PF_EXITING))
> + current->flags & PF_EXITING)) {
> + pr_info("task=%s pid=%d charge bypass\n",
> + current->comm, current->pid);
> goto force;
> + }
>
> /*
> * Prevent unbounded recursion when reclaim operations need to
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 104ef4a01a55..7d9adcde8cf6 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -692,6 +692,8 @@ static void mark_oom_victim(struct task_struct *tsk)
> __thaw_task(tsk);
> atomic_inc(&oom_victims);
> trace_mark_victim(tsk->pid);
> + pr_info("task=%s pid=%d is oom victim now\n",
> + current->comm, current->pid);
> }

Ble this should be s@current@tsk@g. But it didn't really help. I will
have to think about this more.

--
Michal Hocko
SUSE Labs