From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1759714AbcLPMAF (ORCPT <rfc822;w@1wt.eu>);
        Fri, 16 Dec 2016 07:00:05 -0500
Received: from mail-wm0-f66.google.com ([74.125.82.66]:35613 "EHLO
        mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1755003AbcLPL75 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Dec 2016 06:59:57 -0500
Date: Fri, 16 Dec 2016 12:52:54 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>, x86@kernel.org,
        Peter Zijlstra <peterz@infradead.org>, Borislav Petkov <bp@alien8.de>,
        Bruce Schlobohm <bruce.schlobohm@intel.com>,
        Roland Scheidegger <rscheidegger_lists@hispeed.ch>,
        Kevin Stanton <kevin.b.stanton@intel.com>,
        Allen Hung <allen_hung@dell.com>, stable@vger.kernel.org
Subject: Re: [patch 2/2] x86/tsc: Force TSC_ADJUST register to value >= zero
Message-ID: <20161216115254.GA18902@gmail.com>
References: <20161213131115.764824574@linutronix.de>
 <20161213131211.397588033@linutronix.de>
 <alpine.DEB.2.20.1612161121140.3470@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1612161121140.3470@nanos>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Thomas Gleixner <tglx@linutronix.de> wrote:

> We have two options:
> 
> 1) Disable TSC deadline timer by default and force users with sane machines
>    to enable it on the kernel command line.
> 
>    Upside:   Very small patch
>    
>    Downside: Degrades existing setups on sane machines, keeps TSC unusable
>       	     on affected machines. We have no idea what other hidden side
>       	     effects the TSC_ADJUST tinkering has. If there are any, they
>       	     ain't be nice ones.
> 
> 2) Push the whole TSC_ADJUST sanitizing machinery into stable
> 
>    Upside:   Does not affect sane machines and gives a benefit to users of
>    	     affected machines
> 
>    Downside: Rather large patch, but not that risky either. Needs a few
> 	     eyes and good test coverage though
> 
> Thoughts?

I'd go for #2, because #1 is essentially turning it off for almost everyone.

We can still do #1 and push it back to -stable as well if #2 fails.

But I'd suggest we delay the stable backporting until it's been upstream a bit.

Thanks,

	Ingo