Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5057282imm; Tue, 18 Sep 2018 03:44:43 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda3by328jzc3Y/yv35lOHIpw/Lptomu7WSZG1fM16Z28LB0Zf9IXOLKVmQQAx4qWDn5rh/K X-Received: by 2002:a65:5004:: with SMTP id f4-v6mr27053543pgo.54.1537267483250; Tue, 18 Sep 2018 03:44:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537267483; cv=none; d=google.com; s=arc-20160816; b=mWQD1YbfA/I/xYGMjHJpoAY0W7LO06wuCgkFTb7XOa92uXTpgaQMJbkgsl7qJzddmq +FxedG4quZehiyFLSe2sLYnTlgrXHzu6+fTPbq0+A5nji3Ip4kANpeHz1u3d5RM/7crV +WX/mIf+CmKTnauev/WTHE6Bj4mH9/sKX8lMcfgKqQJzy/GmCcjMv7QMk1M/DTqVChaL EvQwv6cplyRtc7BdsC7VgfIEC3vJ+UE2q5OJizlvT/f9yqLxtbq5g4yOcXQpEOQ//uKq PkNiHJ5h0/Ky0/VJfU5o86pbKVVsV5OrXDo5Rr7XE+0GqYc1+yP8Tlpjmi4y5NLGYFCE NmEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=Lx1sQTNnyzvnt4iZ8f1bFXoW7Cpd4gKYJQ9h6oAj7Yw=; b=bxPGvWEOF8s/3IeeiUsKgLY4crHP9aImuo2T2U79bG9xF7OJZb8m/HEDUDevDuYfIk Ue9sIEj241jwYoEEulWVBBejTvNV9j/k4j5Oi24UDU9oNWP3Ga5NkIV7o+qCHzfgyS+B PNCAKDnL8+yPSKNhZqfYmFVsUr5dXwCZ2bXGFjFydHzdM9uQCvafkNFsRwB6uQVhlMQR JDSeOecaKkZQeh+RuMHNoCoHKKnQYUiLETG9pgvbnhG6LQmNNvvik/zJukfHQ2zwbKxk /6L6XYO8esr4WRVhR4DSqhwyQvvuNFLn4EmUTf34+4mCYk2n2/oVckzSk5c/t1R2t63M ZCLw== 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 o12-v6si18721445pfd.142.2018.09.18.03.44.28; Tue, 18 Sep 2018 03:44:43 -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 S1728985AbeIRQOI (ORCPT + 99 others); Tue, 18 Sep 2018 12:14:08 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:57415 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727207AbeIRQOH (ORCPT ); Tue, 18 Sep 2018 12:14:07 -0400 Received: from hsi-kbw-5-158-153-55.hsi19.kabel-badenwuerttemberg.de ([5.158.153.55] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g2DSF-0007YN-KN; Tue, 18 Sep 2018 12:42:03 +0200 Date: Tue, 18 Sep 2018 12:41:57 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra cc: John Stultz , Andy Lutomirski , LKML , X86 ML , Matt Rickard , Stephen Boyd , Florian Weimer , "K. Y. Srinivasan" , Vitaly Kuznetsov , devel@linuxdriverproject.org, Linux Virtualization , Paolo Bonzini , Arnd Bergmann , Juergen Gross Subject: Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case In-Reply-To: Message-ID: References: <20180914125006.349747096@linutronix.de> <20180914125118.909646643@linutronix.de> <20180918083055.GJ24106@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 18 Sep 2018, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Thomas Gleixner wrote: > > On Tue, 18 Sep 2018, Peter Zijlstra wrote: > > > > Your memory serves you right. That's indeed observable on CPUs which > > > > lack TSC_ADJUST. > > > > > > But, if the gtod code can observe this, then why doesn't the code that > > > checks the sync? > > > > Because it depends where the involved CPUs are in the topology. The sync > > code might just run on the same package an simply not see it. Yes, w/o > > TSC_ADJUST the TSC sync code can just fail to see the havoc. > > Even with TSC adjust the TSC can be slightly off by design on multi-socket > systems. Here are the gory details: https://lore.kernel.org/lkml/3c1737210708230408i7a8049a9m5db49e6c4d89ab62@mail.gmail.com/ The changelog has an explanation as well. d8bb6f4c1670 ("x86: tsc prevent time going backwards") I still have one of the machines which is affected by this. Thanks, tglx