Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp720808pxb; Tue, 2 Feb 2021 16:39:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJwksuysyMXrXd7Hq24EjskoTkx3xJ0j6m77d1xpVYN8oZCLnYgL+Parf6SRA40Q/BI3lBsM X-Received: by 2002:a50:a6ce:: with SMTP id f14mr618206edc.346.1612312783819; Tue, 02 Feb 2021 16:39:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612312783; cv=none; d=google.com; s=arc-20160816; b=Le8cBX0BibkIXwIlSonsfPTEA9ars4uGN/Sb95wLo1BkjevJY0ESvfuqD3U+Z0zO0d JQIxjB43oAhhn1nm5ILoaBSP5E9dxZGBw0O/lNdvFwwfMIQut9QOLC0l8w1L3oxJc94X MSfqxQI+IigmERZIGZBJAQlkBO1rzWY+jkM/oP45oCeLAFv2xPtC4/3Tvi2i5vWumh5s esbL/pAeLYTOELI/1UPN8w+TY4QXHgfjzjqAKqWl0QRFwi+Q/wNDisKq3bxbePCMNoJf o3q46u0KfbuEV1QlisgIe1rkl3wgf7Gyaw5XGuzrx2aBzUHKoCs7sCMVWMzkI3rEqyJs iItw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=mf7EvOfg8fp+WnApKts/9k7tKTX1sJsGDYo7bqaR6ak=; b=lJLGdhZxs1F5chqQkW1oYzXDz33Wwhu3v/ElL7I6LrsU4EVkRbEN1nTScNuoiLj9Yu qeEc8e0Zuob02i98pae7bCRQBIvXSWP3r3+BVnNvXl/vnlIcKcDScxUgWX7MWDQlvyAV 1zzzgj1rRTN7fxoyDNOJ5klp7gO18MzkV3iIPPrNht9hRyW1sTLz4rd/Sx3IDLXPD7D4 qVGzdJ8ECuavsSYPA7uf+UrxV3LMo0Y+Y21Z4TeEAQwMs6uHmf0cOzBz3AjbBOw4+jbg x+YnwPx+UJvERSB+m1DwfWJy5aHqlMi0JRvofvOYBjCBw+FGhTOUE34kMtISwCKW2D6F hzDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sqt77Tfm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o26si238313edw.74.2021.02.02.16.39.19; Tue, 02 Feb 2021 16:39:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sqt77Tfm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233818AbhBBSgF (ORCPT + 99 others); Tue, 2 Feb 2021 13:36:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:47086 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233821AbhBBOFN (ORCPT ); Tue, 2 Feb 2021 09:05:13 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C42BD65018; Tue, 2 Feb 2021 13:48:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612273738; bh=HStRNDTcPxRrCu+MkU2+DNqIoIO9Qom7WUpPOTv8c1s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sqt77Tfmj4JqDmaLbVs7KKYxZcfPHk6o6/Yux1ydkcC4J+jNQKI2ksx4wxPI+mqpt rdLzMun5vs2gGeCwmnmeR+hTcRosF09hBlt5QwGPtmPlOuaZq6JfQ/z4XTJe1pSHlA GJlkZcFLzYJQivv0C94b46o8wXZGPQaiAVh+VKbY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Thomas Gleixner , Ingo Molnar , "Peter Zijlstra (Intel)" , Lee Jones Subject: [PATCH 4.4 12/28] futex: Set task::futex_state to DEAD right after handling futex exit Date: Tue, 2 Feb 2021 14:38:32 +0100 Message-Id: <20210202132941.679288914@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210202132941.180062901@linuxfoundation.org> References: <20210202132941.180062901@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Thomas Gleixner commit f24f22435dcc11389acc87e5586239c1819d217c upstream. Setting task::futex_state in do_exit() is rather arbitrarily placed for no reason. Move it into the futex code. Note, this is only done for the exit cleanup as the exec cleanup cannot set the state to FUTEX_STATE_DEAD because the task struct is still in active use. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20191106224556.439511191@linutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman --- kernel/exit.c | 1 - kernel/futex.c | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) --- a/kernel/exit.c +++ b/kernel/exit.c @@ -784,7 +784,6 @@ void do_exit(long code) * Make sure we are holding no locks: */ debug_check_no_locks_held(); - futex_exit_done(tsk); if (tsk->io_context) exit_io_context(tsk); --- a/kernel/futex.c +++ b/kernel/futex.c @@ -3255,6 +3255,7 @@ void futex_exec_release(struct task_stru void futex_exit_release(struct task_struct *tsk) { futex_exec_release(tsk); + futex_exit_done(tsk); } long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,