From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Received: from mga17.intel.com ([192.55.52.151]:39595 "EHLO mga17.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1730449AbeLPRjN (ORCPT <rfc822;stable@vger.kernel.org>);
        Sun, 16 Dec 2018 12:39:13 -0500
Date: Sun, 16 Dec 2018 09:39:12 -0800
From: Andi Kleen <ak@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Barry Kauler <bkauler@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jiri Kosina <jkosina@suse.cz>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Casey Schaufler <casey.schaufler@intel.com>,
        Asit Mallick <asit.k.mallick@intel.com>,
        Arjan van de Ven <arjan@linux.intel.com>,
        Jon Masters <jcm@redhat.com>,
        Waiman Long <longman9394@gmail.com>,
        Dave Stewart <david.c.stewart@intel.com>,
        Kees Cook <keescook@chromium.org>, stable@vger.kernel.org
Subject: Re: SCHEDL_SMT forced on!
Message-ID: <20181216173912.GQ25620@tassilo.jf.intel.com>
References: <CABWT5ygnqd3-EdJ2MeE8CPo=D53NSaTps0qAR1ETX98XaO6_pA@mail.gmail.com>
 <20181216082746.GB29097@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181216082746.GB29097@kroah.com>
Sender: stable-owner@vger.kernel.org
List-ID: <stable.vger.kernel.org>

On Sun, Dec 16, 2018 at 09:27:46AM +0100, Greg KH wrote:
> On Sun, Dec 16, 2018 at 02:21:55PM +0800, Barry Kauler wrote:
> > Mr Gleixner,
> > I was upset when I compiled 4.14.87 found that SCHED_SMT had been
> > forced on. At the time, I just reported it to my blog, and posted a
> > question about it to a couple of forums, and stayed with an earlier
> > kernel.
> > 
> > However, when 4.14.88 came out, and still the same situation, alarm
> > bells went off, and I looked through the kernel changelog. Found it,
> > 4.14.86:
> > 
> > "x86/Kconfig: Select SCHED_SMT if SMP enabled"
> > 
> > Then:
> > 
> > "CONFIG_SCHED_SMT is enabled by all distros, so there is not a real point to
> >     have it configurable. ..."
> > 
> > ...that is a lie. It would be correct to state that is true of the
> > distros you use, and presumably also for all of you guys who signed
> > off on it.
> > 
> > Puppy Linux is an example of a distro that has mostly not had
> > SCHED_SMT enabled. Ditto for most of the forks of Puppy. Two distros
> > that I currently maintain, Quirky and EasyOS (easyos.org) have SMP
> > enabled but not SCHED_SMT.
> > 
> > The difference between them is important, they should remain
> > independently settable. I am so surprised that all of you guys went
> > along with forcing it on.
> 
> Is having this option enabled causing a problem for you?  Does it cause
> slowdowns or runtime issues?

>>From the blog:

>>>
Note, way back in the early days when I was first compiling the kernel for multi-core CPUs, SMT (hyperthreading), which simulates more than one core for each actual core, was causing file corruption. So, disabled it, and never trusted it after that.
<<

Since nearly everyone else has the option enabled we 
are quite confident there is no data corruption caused by it.
So there shouldn't be any reason to turn it off.

-Andi