From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932585AbcE0ILL (ORCPT <rfc822;w@1wt.eu>);
	Fri, 27 May 2016 04:11:11 -0400
Received: from mail-wm0-f67.google.com ([74.125.82.67]:35881 "EHLO
	mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932077AbcE0ILB (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 27 May 2016 04:11:01 -0400
Date: Fri, 27 May 2016 10:10:59 +0200
From: Michal Hocko <mhocko@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        David Rientjes <rientjes@google.com>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        Johannes Weiner <hannes@cmpxchg.org>, Oleg Nesterov <oleg@redhat.com>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] oom_reaper: don't call mmput_async() on uninitialized mm
Message-ID: <20160527081059.GE27686@dhcp22.suse.cz>
References: <1464336081-994232-1-git-send-email-arnd@arndb.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1464336081-994232-1-git-send-email-arnd@arndb.de>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri 27-05-16 10:00:48, Arnd Bergmann wrote:
> The change to the oom_reaper to hold a mutex inside __oom_reap_task()
> accidentally started calling mmput_async() on the local
> mm before that variable got initialized, as reported by gcc
> in linux-next:
> 
> mm/oom_kill.c: In function '__oom_reap_task':
> mm/oom_kill.c:537:2: error: 'mm' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This rearranges the code slightly back to the state before patch
> but leaves the lock in place. The error handling in the function
> still looks a bit confusing and could probably be improved
> but I could not come up with a solution that made me happy
> for now.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: mmotm ("oom_reaper: close race with exiting task")

Thanks for catching that Arnd?

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/oom_kill.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 1685890d424e..255cb5f48019 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -447,7 +447,7 @@ static bool __oom_reap_task(struct task_struct *tsk)
>  	struct task_struct *p;
>  	struct zap_details details = {.check_swap_entries = true,
>  				      .ignore_dirty = true};
> -	bool ret = true;
> +	bool ret;
>  
>  	/*
>  	 * We have to make sure to not race with the victim exit path
> @@ -472,13 +472,16 @@ static bool __oom_reap_task(struct task_struct *tsk)
>  	 * is no mm.
>  	 */
>  	p = find_lock_task_mm(tsk);
> -	if (!p)
> -		goto unlock_oom;
> +	if (!p) {
> +		mutex_unlock(&oom_lock);
> +		return true;
> +	}
>  
>  	mm = p->mm;
>  	if (!atomic_inc_not_zero(&mm->mm_users)) {
>  		task_unlock(p);
> -		goto unlock_oom;
> +		mutex_unlock(&oom_lock);
> +		return true;
>  	}
>  
>  	task_unlock(p);
> @@ -527,6 +530,7 @@ static bool __oom_reap_task(struct task_struct *tsk)
>  	 * to release its memory.
>  	 */
>  	set_bit(MMF_OOM_REAPED, &mm->flags);
> +	ret = true;
>  unlock_oom:
>  	mutex_unlock(&oom_lock);
>  	/*
> -- 
> 2.7.0
> 

-- 
Michal Hocko
SUSE Labs