Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2232401pxb; Mon, 8 Mar 2021 19:00:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJzMxfVSgslVqZ6SKT0e/eOBmM+KQdT9xyBbyYl8UE+cet1L7yoAKZwSGnouBQeVq79DXS0d X-Received: by 2002:a17:906:304a:: with SMTP id d10mr17886330ejd.507.1615258858102; Mon, 08 Mar 2021 19:00:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615258858; cv=none; d=google.com; s=arc-20160816; b=dR9laSF3JnvTiZ+TOuZdlSdOq3w8GceVgBi+BbO9g3d+2HHwran25EnQoKEAz2lNzF LZSG8UG9neZCk4T/2+5d6n4DrVl74v3QGoE68UqvMwoZOUyoE1XvMXD0bVxpi2SM5X49 zp0EM0bM9ZAsGmmHCi5kFTkWM4usxaBbbttQbPbRPST+vVp2P5THfYDcI2JuMMgiAYtt ei/h5MHwN0NpOvM47e+mfAMWAo4Kw7sqHsixgkUHWuj9FRb7CT2C8y2FETmNO9P2pOR7 JbWAyRs/JvHvU5+gmbiW+elXjxiMoA1PFqVbuBccveJjVTOlXR1cbT+sx+vtq+uCP+HT 5x1g== 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 :message-id:date:subject:cc:to:from; bh=hIWMm/jZjLiJlQRZ65CjLuTgZiKbY+xMRh3XA1irg6E=; b=qVavEQB6LLV32H1SvMGgBpjcbYTVzFn7UrX/iRcPPtScDHnTG041dDtSguPKK9lO/T TdGfyKQbWfwnPycQLpKk/GJVDCbZQ602v+GWBcocpM+C1HSAK/C/sD36ccZWaZF5BH/a Z2uaQ6OAajFen8Da0zqVBlsh9V0hzq7R3LhLwWW/WwSwWhDZ8E2bmEdmsqrT/HCfqYju iR7cvaPPj/6tspYeh7OTD3LOSItFPeaJk4A+BA3O9D0I1WNXoYL1JyoXfJdVITnm7BCQ wgb8AN/a+JD0xs8JKqq8KaxsSnFXkvBH7OMtCN/fXKUpx4Suo0M6+SiK9Ieaeif3ln35 9sjQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g20si7813780ejf.364.2021.03.08.19.00.35; Mon, 08 Mar 2021 19:00:58 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229969AbhCIC71 (ORCPT + 99 others); Mon, 8 Mar 2021 21:59:27 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:13873 "EHLO szxga07-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229599AbhCIC7Q (ORCPT ); Mon, 8 Mar 2021 21:59:16 -0500 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4DvfyJ6HPqz8vQn; Tue, 9 Mar 2021 10:57:28 +0800 (CST) Received: from code-website.localdomain (10.175.127.227) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.498.0; Tue, 9 Mar 2021 10:59:04 +0800 From: Zheng Yejian To: , , , CC: , , , , Subject: [PATCH 4.4 0/3] Backport patch series to update Futex from 4.9 Date: Tue, 9 Mar 2021 11:06:02 +0800 Message-ID: <20210309030605.3295183-1-zhengyejian1@huawei.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Lee sent a patchset to update Futex for 4.9, see https://www.spinics.net/lists/stable/msg443081.html, Then Xiaoming sent a follow-up patch for it, see https://lore.kernel.org/lkml/20210225093120.GD641347@dell/. These patchsets may also resolve following issues in 4.4.260 which have been reported in 4.9, see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=linux-4.4.y&id=319f66f08de1083c1fe271261665c209009dd65a > /* > * The task is on the way out. When the futex state is > * FUTEX_STATE_DEAD, we know that the task has finished > * the cleanup: > */ > int ret = (p->futex_state = FUTEX_STATE_DEAD) ? -ESRCH : -EAGAIN; Here may be: int ret = (p->futex_state == FUTEX_STATE_DEAD) ? -ESRCH : -EAGAIN; > raw_spin_unlock_irq(&p->pi_lock); > /* > * If the owner task is between FUTEX_STATE_EXITING and > * FUTEX_STATE_DEAD then store the task pointer and keep > * the reference on the task struct. The calling code will > * drop all locks, wait for the task to reach > * FUTEX_STATE_DEAD and then drop the refcount. This is > * required to prevent a live lock when the current task > * preempted the exiting task between the two states. > */ > if (ret == -EBUSY) And here, the variable "ret" may only be "-ESRCH" or "-EAGAIN", but not "-EBUSY". > *exiting = p; > else > put_task_struct(p); Since 074e7d515783 ("futex: Ensure the correct return value from futex_lock_pi()") has been merged in 4.4.260, I send the remain 3 patches. Peter Zijlstra (1): futex: Change locking rules Thomas Gleixner (2): futex: Cure exit race futex: fix dead code in attach_to_pi_owner() kernel/futex.c | 209 +++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 177 insertions(+), 32 deletions(-) -- 2.25.4