Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp395761pxb; Wed, 24 Feb 2021 05:17:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJwXxvFntGNPDDelGjdBtdM+q9fw0tueUjF1cFqvQMFymSwkl3L/SguBafWtP7sfAJFrigoy X-Received: by 2002:a17:906:3393:: with SMTP id v19mr3456092eja.403.1614172653352; Wed, 24 Feb 2021 05:17:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614172653; cv=none; d=google.com; s=arc-20160816; b=SIaUHMxhPMaoVa6Ip67l3N5Wm07AxnlssBMRICwGJx0bM7pXybzKrqwDcArZKSiv50 ZJCt5qzIJ0PwCWfOk7bptszqoLhxY/w4JA0IeSV00145CBGpfG+FFGHbbJznbuBkrvxX FU1vi0/ey7eenoyIv4Ph18c5trgdfffmOU6ZKKaxNdRiG1fmweU6Xoc7NdNi08WLqThs eVneFH5gWkqnwDTs0U8LpEMZZbn6qWVaEVA77g2QBbjRct47ZjXD0cARIbrjMhtJlkoI OoJ3QzSR2bE6Qz5HfjzFMxRomBOUgoVJwAmjswIAHhnzeHaYU2o3UOVI1obk1EY3zusV EX9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=y1amc0xUUDXKyMkYpBNAZwR5P9bhKoCJSS4XEZ56VYA=; b=sznyhdpce103AX0vt+1+TOkG0Tl16k58F6OIlecxjaZHjU2I/kQY6JkBygbbLhHHLX rlXTRBs8Zq1YdcvWqzDRZkCzpOxd733Zfay6dywZlVZC6yp5PoPbRBh3lXcxu5mybIcx 8JL/J32apPPo8QxyCG+NPqVxwx/bOBced0nd7z8qnxbOmjaPO8ldsec7kSJnaI7gTHIH TU9p1I/U4YT+XQElUSxhPnfnTT1dumPVuxVk8p72YHwR9snJV9AuTV6rsDmIHMQp88Yc Ja6RzBpoxKGJvL1NAO8+8/apwDNHjHjopl0ST0TASzmfZdyEAMz/KxacwFOKCDLwjWUJ PvQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=OdI1Nh16; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id js14si1230949ejc.697.2021.02.24.05.16.16; Wed, 24 Feb 2021 05:17:33 -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=@linaro.org header.s=google header.b=OdI1Nh16; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232686AbhBXLUf (ORCPT + 99 others); Wed, 24 Feb 2021 06:20:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235048AbhBXLUE (ORCPT ); Wed, 24 Feb 2021 06:20:04 -0500 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 111F3C061574 for ; Wed, 24 Feb 2021 03:19:19 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id h98so1489635wrh.11 for ; Wed, 24 Feb 2021 03:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=y1amc0xUUDXKyMkYpBNAZwR5P9bhKoCJSS4XEZ56VYA=; b=OdI1Nh16csmUafIBo4cGakR3MV48vT6+emCMcit7JQ8pv8fbf09Pzu4qgDmXBRrxVP MqrSktI0jUbZV58GN5mmyAj/Nk9wJDerYysxbJ90AUNx+lniy7sBZP6sd9ZtgkblWGGd 6GW7SnoT0vMzndPTdWB2Pt8+OgVixRhhdjf9D+cUDSdvp2D4lwctvN7XRC2LzJVR07Lx m8BViKyEJyo+5D3AbO01NLWbGPXdJupsDFQSd7MSA53huqr5wP+5IgWN4psSl88Wb72e aLjiAtfM1ws8K/9zMSjXGtA6/VPWMl3bySW8fsX+O/gQCudq6jdUeNuvetls6aSPKG9M wSGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=y1amc0xUUDXKyMkYpBNAZwR5P9bhKoCJSS4XEZ56VYA=; b=CB/zdW3Smi6yGoH1l2AYLpDMMc2cQBQ+asymNwli5Q6y+0RWaATLijCr26UwNRl8rt jchZ+DmzL9ApqkMJZEOqpXQ8QheGjM3DquCQGwybSFx0sOehrDmNzyy5yA6AAKMifLuQ lCFmqZqZgD/233Bmw7dbggOjlRleXn059vkRjY6+HLYTs2CqpQW6z7HDWN4/D2XQg84H JVcL/rF7LzHYlmHOJWyaLjni9BVYW0H3O29N4e563BXoLZgSVAbO4r9zeJJ9dkAUaNQ3 E4idpsdE8iRSHDLu1zAGBxtlvGLiEo8ly2dIxhX40VQ9mwgaFcAOym8GOUmD1xNYUvqq Mo/g== X-Gm-Message-State: AOAM530qxA/zlw5PJDQI0oB5iz+YJ7FGMR/bAPxq/t4sG3Pd7vpGQuBO yqi+etM1nxYtIAbFpnvOv2+uOw== X-Received: by 2002:a5d:6808:: with SMTP id w8mr28828323wru.290.1614165557793; Wed, 24 Feb 2021 03:19:17 -0800 (PST) Received: from dell ([91.110.221.155]) by smtp.gmail.com with ESMTPSA id e17sm3583648wro.36.2021.02.24.03.19.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Feb 2021 03:19:17 -0800 (PST) Date: Wed, 24 Feb 2021 11:19:15 +0000 From: Lee Jones To: Zheng Yejian Cc: gregkh@linuxfoundation.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, cj.chengjian@huawei.com, judy.chenhui@huawei.com, zhangjinhao2@huawei.com Subject: Re: [PATCH 4.9.y 1/1] futex: Fix OWNER_DEAD fixup Message-ID: <20210224111915.GA641347@dell> References: <20210223144151.916675-1-zhengyejian1@huawei.com> <20210223144151.916675-2-zhengyejian1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210223144151.916675-2-zhengyejian1@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Feb 2021, Zheng Yejian wrote: > From: Peter Zijlstra > > commit a97cb0e7b3f4c6297fd857055ae8e895f402f501 upstream. > > Both Geert and DaveJ reported that the recent futex commit: > > c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex") > > introduced a problem with setting OWNER_DEAD. We set the bit on an > uninitialized variable and then entirely optimize it away as a > dead-store. > > Move the setting of the bit to where it is more useful. > > Reported-by: Geert Uytterhoeven > Reported-by: Dave Jones > Signed-off-by: Peter Zijlstra (Intel) > Cc: Andrew Morton > Cc: Linus Torvalds > Cc: Paul E. McKenney > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Fixes: c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex") > Link: http://lkml.kernel.org/r/20180122103947.GD2228@hirez.programming.kicks-ass.net > Signed-off-by: Ingo Molnar > Signed-off-by: Zheng Yejian Why have you dropped my Reviewed-by? > --- > kernel/futex.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/kernel/futex.c b/kernel/futex.c > index b65dbb5d60bb..604d1cb9839d 100644 > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -2424,9 +2424,6 @@ static int __fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q, > int err = 0; > > oldowner = pi_state->owner; > - /* Owner died? */ > - if (!pi_state->owner) > - newtid |= FUTEX_OWNER_DIED; > > /* > * We are here because either: > @@ -2484,6 +2481,9 @@ static int __fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q, > } > > newtid = task_pid_vnr(newowner) | FUTEX_WAITERS; > + /* Owner died? */ > + if (!pi_state->owner) > + newtid |= FUTEX_OWNER_DIED; > > if (get_futex_value_locked(&uval, uaddr)) > goto handle_fault; -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog