Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2234785imm; Thu, 7 Jun 2018 07:29:06 -0700 (PDT) X-Google-Smtp-Source: ADUXVKINYbynbnlA05KJJO1UNW5EhjJI4BeiEiKjyLwDR7pknCdz+N7ucs+8UJrIBujMRv5pbOHN X-Received: by 2002:a65:42c2:: with SMTP id l2-v6mr1761583pgp.237.1528381746431; Thu, 07 Jun 2018 07:29:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528381746; cv=none; d=google.com; s=arc-20160816; b=fVqt1yx9Ox2WQhOouyQ7XhcHohF/LBWtWCumssyncg9cS8+ciK6T8vJRpzlp5b2bkQ 2WAzKqAWsVWnJTp10ouIdOeTDQG/8xGKSuPc0x+lNJbQr4996TFFAsOqFMumVTYfzooQ /neDyYbyVWOH4aii/Jgr3JSnu8ZSHzrznvvFjzRlBcar/ijN+H985FUWJABqmIkC+fIZ TpX+2zTtr4ZBYBu4CJCasmRNwWMdouTdOgKObeECrYBwIZSCGZDvet6joXxMSXzaoG4I D52HZT8df02Z2Qa+5sKqvXqNAB6n+xI35iv3dYyEYiUihYq/bobex9CaLHUYVVIoWzeN SASQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=UfQv07gQwxklW0G6qhP7mmbQfZASL75QGfaToISLtUo=; b=el4/og0Ke/nETc8S+8NvF4G7ys0zBtsJ85pbiXxe075y1uuiJOhXx98tTwEbp07HeS tohV1BcuSiyPS7EtgsBYv/7MX9/j90a9CpU7idnur4KWbz0onsouVaVpGdydcr80L0lX 5RZ1V04qH/sWfuJTPs7EEuv8hQJZM8wSNDS1n5eMaLRqiTzzRDswDxewjJ+vibBQItYd 52qVND/2IQptAuPp/GGlOXZw+d9bN4VfaYEEQ8AvFVI+PzMIH4Y+E04AJTXK1FHxz+x3 hcE/g7xc0LQOdcgClDKTyn/uc9TKT9IVHOagb9qhX0XQZ2mB34gr0cVE4QwPZeP1VQkc mV6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e12-v6si35107128plt.209.2018.06.07.07.28.52; Thu, 07 Jun 2018 07:29:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933625AbeFGO0b (ORCPT + 99 others); Thu, 7 Jun 2018 10:26:31 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40176 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932814AbeFGO03 (ORCPT ); Thu, 7 Jun 2018 10:26:29 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbp-0005Zn-8N; Thu, 07 Jun 2018 15:09:49 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvb2-0002s1-Md; Thu, 07 Jun 2018 15:09:00 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Thomas Gleixner" , "Linus Torvalds" , "John Stultz" , "Peter Zijlstra" , "Anna-Maria Gleixner" , keescook@chromium.org, "Christoph Hellwig" , "Ingo Molnar" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 133/410] hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers) In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Anna-Maria Gleixner commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream. The POSIX specification defines that relative CLOCK_REALTIME timers are not affected by clock modifications. Those timers have to use CLOCK_MONOTONIC to ensure POSIX compliance. The introduction of the additional HRTIMER_MODE_PINNED mode broke this requirement for pinned timers. There is no user space visible impact because user space timers are not using pinned mode, but for consistency reasons this needs to be fixed. Check whether the mode has the HRTIMER_MODE_REL bit set instead of comparing with HRTIMER_MODE_ABS. Signed-off-by: Anna-Maria Gleixner Cc: Christoph Hellwig Cc: John Stultz Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: keescook@chromium.org Fixes: 597d0275736d ("timers: Framework for identifying pinned timers") Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings --- kernel/hrtimer.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -1197,7 +1197,12 @@ static void __hrtimer_init(struct hrtime cpu_base = &__raw_get_cpu_var(hrtimer_bases); - if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS) + /* + * POSIX magic: Relative CLOCK_REALTIME timers are not affected by + * clock modifications, so they needs to become CLOCK_MONOTONIC to + * ensure POSIX compliance. + */ + if (clock_id == CLOCK_REALTIME && mode & HRTIMER_MODE_REL) clock_id = CLOCK_MONOTONIC; base = hrtimer_clockid_to_base(clock_id);