Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2554549pxj; Mon, 10 May 2021 05:49:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIUgOlaQTjt26Tk3wACDtGw/TWxwfh5fEQsoLnx0NufDVL6SvDKQdIHPFxG+rmJKVPxUbq X-Received: by 2002:a17:906:79c8:: with SMTP id m8mr25988677ejo.260.1620650986135; Mon, 10 May 2021 05:49:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620650986; cv=none; d=google.com; s=arc-20160816; b=XQF7MxYTMj66VCDTXoyEtcVAAKT4iloIB52mzh22xeHRCPvTeC6GOWf3f+oIDdLCAK QVLF8/WAWKZm3hoFw4QPvhxbEYt/qzU8J0+wJAsUIeEiv31bxI/VPSjYv/0r4dAskp4H u8c9GyyLDhgHU5CYj/aNRmYw0bcCuzVJsD1J8jDfOK+YK2Z602CQ5gz1IgETJoLNwJvn 4lG51lolMmNngEQZyfNbqOVF6jEYI5QDC7TXrHM0LcbdLo3VzBIOHiYaG3UG7lLjPHtI hFa/fRW5neD5C95vJHM6Cwn1HNaxcb2ceyEqq84epMlHJGmuVTZF7xp+OKBX3m+mMw+W 4A1A== 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=qP1zS1IE66r45ggtvOCdRk0/8DQ2VboAyBki4IVlT+o=; b=rjwDIayZFsjfEp9XkC7iEMkAG7NDroy37la+klLs8yrxIKLgMrOyWudjug5xNiN0lM xE0tfTrgQL1i1WAg9m5ZjiTQkEXTHIplRo6zn4n8pTKYuVhPV6ti5338u2DjabsR9sUC khWjsGcu1DGF26W45MOEtYpvzpbifFFfArppsto2sEHN3QLGzYpv9xt2L35tx2dfFoOR bKqc62OLrDPoEglEiT8/VQCkpCq9XRmi5DgCHtc7QQvg6aZ6CUAgh+Uh6WV6zOyullv6 w+yr2YvpKAJaCwqsJ2Eya/CijEp1NC10sLJo4O1+2JwbX5sYs910kkx8krKW5D77xzOh BkbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Id4VGtSE; 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 y4si12967662eds.430.2021.05.10.05.49.15; Mon, 10 May 2021 05:49:46 -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=Id4VGtSE; 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 S1347658AbhEJMgm (ORCPT + 99 others); Mon, 10 May 2021 08:36:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:58324 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237438AbhEJLPF (ORCPT ); Mon, 10 May 2021 07:15:05 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C7B4F61108; Mon, 10 May 2021 11:10:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620645058; bh=rAGappilp1e9ZWphv4CQintWd2/j0kzuJ2+3dx1DlRQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Id4VGtSE3FAwdvgJEh1lzj4B90BILiOfzBm59KAkys0n5L6aNu7cXrqRdq4d2o9My 3pn1meq1dWAXZF2O+kDfXOT9UnW1A4Rb4c4u/pUI4U9wmULt9jtNBem5sRfd7J6D1Y u7RiDgcMDK7uOeTm3PAwZDZ2cZ3PbXdUf74TCyIM= 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 5.12 333/384] futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI Date: Mon, 10 May 2021 12:22:02 +0200 Message-Id: <20210510102025.766946593@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210510102014.849075526@linuxfoundation.org> References: <20210510102014.849075526@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 cdf78db4070967869e4d027c11f4dd825d8f815a upstream. FUTEX_LOCK_PI does not require to have the FUTEX_CLOCK_REALTIME bit set because it has been using CLOCK_REALTIME based absolute timeouts forever. Due to that, the time namespace adjustment which is applied when FUTEX_CLOCK_REALTIME is not set, will wrongly take place for FUTEX_LOCK_PI and wreckage the timeout. Exclude it from that procedure. Fixes: c2f7d08cccf4 ("futex: Adjust absolute futex timeouts with per time namespace offset") Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210422194704.984540159@linutronix.de Signed-off-by: Greg Kroah-Hartman --- kernel/futex.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/kernel/futex.c +++ b/kernel/futex.c @@ -3781,7 +3781,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uad t = timespec64_to_ktime(ts); if (cmd == FUTEX_WAIT) t = ktime_add_safe(ktime_get(), t); - else if (!(op & FUTEX_CLOCK_REALTIME)) + else if (cmd != FUTEX_LOCK_PI && !(op & FUTEX_CLOCK_REALTIME)) t = timens_ktime_to_host(CLOCK_MONOTONIC, t); tp = &t; } @@ -3975,7 +3975,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user t = timespec64_to_ktime(ts); if (cmd == FUTEX_WAIT) t = ktime_add_safe(ktime_get(), t); - else if (!(op & FUTEX_CLOCK_REALTIME)) + else if (cmd != FUTEX_LOCK_PI && !(op & FUTEX_CLOCK_REALTIME)) t = timens_ktime_to_host(CLOCK_MONOTONIC, t); tp = &t; }