Received: by 2002:a05:6520:4211:b029:f4:110d:56bc with SMTP id o17csp2108368lkv; Thu, 20 May 2021 03:36:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHuZ0u8xwNGgf+dPkjGc7KL3FtTPoTMnEXCeuP0+X0X2G0yUt/UrAfLSPFbPwrFw9SroWT X-Received: by 2002:a05:6e02:1a67:: with SMTP id w7mr3764280ilv.137.1621506987888; Thu, 20 May 2021 03:36:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621506987; cv=none; d=google.com; s=arc-20160816; b=CmylwIcF6hNZyz7Pt2D8FKW0vANiSnHgxkDn54/3x9PykGIawbyoE2vkTttB0GZgZN GEuK4GJl5XSAlMuMfnRo0vz74tpgm4Y/07xUNgCkqgirsPfcQFj2GptMqez26ziLglB1 /wXzWXc2P+K0irBJM2UpGsik3rWqE2fm1ARCa96sJ/Sy9P2adTO8lAXqOk/7rUhSjwER f/aXhvBdjGCxTXuwnhiNxFAkl3l9ut42fgsR5Svzqn0VpS51FIkJd7+HACmib61TNBAq n6DY7+gdxnzmbif8Lj+QUAVqzIuZ4FWD3tW1KCeYuePQ/5L5pGP7nPNmIPnif/urRq1D LecQ== 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=3ZB5+H1fUJL0JN0mTGqudoBdEBgg6DD3Bs4xijXUKkE=; b=F7re03V+dt5GMGmqigDP3ZL+i5uaW+MbQEwR87vM/IaECLqAFKXH4Tf5v2MP8PGMlP jwiyUf6w+X41hK9Yn2nzDKSAVEjIFCQcu9Bbnft3B6YxhBbAtb/7h8VxHQ09DEOMC4BJ zKKsr9La0lK4fWs0bC1ll19i9F9OvhTFOpxbh4Bk59i4RSWl+ElAtmQiz5GR/XL3oj1W NLDyBx9R5Dd8l6yfulWMnxa4yeZHUZNibXikAEHshYZ1PW0uSIFYoAVSPuvGs5kkDaII QsZSzGCXeNJP/Nrz9DMxWVpdNMXPApGoQzeWNboiQNez+EXW18RODPz5NT5CAl25q9qo 6XyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=wx8Ukjm5; 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 i5si1911322jaj.101.2021.05.20.03.35.52; Thu, 20 May 2021 03:36:27 -0700 (PDT) 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=wx8Ukjm5; 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 S237747AbhETKf1 (ORCPT + 99 others); Thu, 20 May 2021 06:35:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:52120 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236176AbhETKWa (ORCPT ); Thu, 20 May 2021 06:22:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E0362619D2; Thu, 20 May 2021 09:48:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621504096; bh=cg3MS0SYNuGLvo5vcX/I4vDYPzRBGZQ+HXBDrrCyMfE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wx8Ukjm5FtIs6zYicLfeHQW3o0YuZZlGrkXiQIkaWFsYFo6u17+bpygHPk1sXjej+ Hw/1chjLFC9p2gvl6Xoid+/iul6eYyOGgVewnu0uDln1Yi0Oo3sCdYw95M1RXhXkXk rupyrJRhwuqMYd31UND+ZEP5CoNzcg5kQ0VJOpq8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Thomas Gleixner , "Peter Zijlstra (Intel)" Subject: [PATCH 4.14 089/323] Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") Date: Thu, 20 May 2021 11:19:41 +0200 Message-Id: <20210520092123.143275848@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210520092120.115153432@linuxfoundation.org> References: <20210520092120.115153432@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 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 upstream. The FUTEX_WAIT operand has historically a relative timeout which means that the clock id is irrelevant as relative timeouts on CLOCK_REALTIME are not subject to wall clock changes and therefore are mapped by the kernel to CLOCK_MONOTONIC for simplicity. If a caller would set FUTEX_CLOCK_REALTIME for FUTEX_WAIT the timeout is still treated relative vs. CLOCK_MONOTONIC and then the wait arms that timeout based on CLOCK_REALTIME which is broken and obviously has never been used or even tested. Reject any attempt to use FUTEX_CLOCK_REALTIME with FUTEX_WAIT again. The desired functionality can be achieved with FUTEX_WAIT_BITSET and a FUTEX_BITSET_MATCH_ANY argument. Fixes: 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210422194704.834797921@linutronix.de Signed-off-by: Greg Kroah-Hartman --- kernel/futex.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/kernel/futex.c +++ b/kernel/futex.c @@ -3885,8 +3885,7 @@ long do_futex(u32 __user *uaddr, int op, if (op & FUTEX_CLOCK_REALTIME) { flags |= FLAGS_CLOCKRT; - if (cmd != FUTEX_WAIT && cmd != FUTEX_WAIT_BITSET && \ - cmd != FUTEX_WAIT_REQUEUE_PI) + if (cmd != FUTEX_WAIT_BITSET && cmd != FUTEX_WAIT_REQUEUE_PI) return -ENOSYS; }