Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2546182imm; Thu, 16 Aug 2018 11:14:24 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzqKItu7XgGi+yiiO0oX+5n1PkWC4N+nIuzOXyBH0ykJZaDTg1Dw0unO88rroEEKYparpuW X-Received: by 2002:a17:902:1566:: with SMTP id b35-v6mr29872729plh.135.1534443264574; Thu, 16 Aug 2018 11:14:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534443264; cv=none; d=google.com; s=arc-20160816; b=Dg7bvlzhKN63BK72vcpYe3DdxkOOFjuCoKEs2nlPFEQa5aXGdttXEBoaYmhFnp3b3M /Cko6QJ9s6I6ZWU02caFm/DOzwGACZaEHEHgbjIQjw2k9UVUsQzer0vOQ4e08g+aDVAm IrtImSFXQ4rtusqN8J1QV9MG3A676pt4pTXnGqqioabCgq0I8JOqHdwHmRm0fAzXb6id s0YOLlTVvF0bfsNtP18ov4r/rEOcJmmtVa7PNp2C39wcPpYK4ln/hM7Ax9RrUeS8XoO3 +PbwjV7uJnqMoJV44nmZZXgbrFmKsgpAjb6crpTyKjqlJJYn5EBQIcg7WPtaBnySstK3 nJbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=hDu+sYq+45kqX4NBYHjWWr5vuZLmgVCplOOgv28qVNs=; b=sn9pg1yuBRSUrmHhE/JuMT49jMP5+TrJlp7AKNHvD+doXmdoBwo5bOZkU7yfNuDVDH dAU8gfEWRPKUuUlGwjfwtHXXidwVEItGvT3gp8cx4m1MyXZYir2xR2Yy6dwN0PACVeLb j6SVQQ4QVLndVkshXSFT630wXTaPve8UhY3+dCJfkO5O0Ji36BeHMz8JZjy87qWd2jDt 4j8wYxZaOOmsK8QQig76PSmiF+xLxBk12ItsLvvMXnAyFQMtIFIgzhJ2OOUgCt+y3VNr qitsYH86xwzzYmCWPLsAGUTY+fyXaFY7xF+NbpkhrCM2qnDjZZWcxKxAryIy/ckxf5os GeAQ== 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 66-v6si24512516plb.428.2018.08.16.11.14.09; Thu, 16 Aug 2018 11:14:24 -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 S2390663AbeHPNJs (ORCPT + 99 others); Thu, 16 Aug 2018 09:09:48 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:43362 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729663AbeHPNJs (ORCPT ); Thu, 16 Aug 2018 09:09:48 -0400 Received: from localhost (unknown [37.170.164.166]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 6F5EF40B; Thu, 16 Aug 2018 10:12:16 +0000 (UTC) Date: Thu, 16 Aug 2018 12:12:12 +0200 From: Greg Kroah-Hartman To: Byron Stanoszek Cc: Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH 4.18 00/79] 4.18.1-stable review Message-ID: <20180816101212.GF9141@kroah.com> References: <20180815173254.GB22317@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 16, 2018 at 12:39:29AM -0400, Byron Stanoszek wrote: > On Wed, 15 Aug 2018, Greg Kroah-Hartman wrote: > > > On Wed, Aug 15, 2018 at 01:24:25PM -0400, Byron Stanoszek wrote: > > > Hi Greg & Thomas, > > > > > > I'd like to report a regression in Linux 4.18.1 regarding the L1TF patches. > > > > > > The kernel no longer thinks I have SMT enabled in the BIOS. This works fine in > > > 4.18.0. > > > > > > Not sure if this matters, but in my particular 4-core system, my third core is > > > broken (core #2). So I must boot using "maxcpus=2" and then online the other > > > cores & SMT threads at startup using: > > > > > > echo 1 > /sys/devices/system/cpu/cpu3/online > > > echo 1 > /sys/devices/system/cpu/cpu4/online > > > echo 1 > /sys/devices/system/cpu/cpu5/online > > > echo 1 > /sys/devices/system/cpu/cpu7/online > > > > > > In 4.18.0, dmesg shows: > > > > > > smpboot: Booting Node 0 Processor 3 APIC 0x6 > > > smpboot: Booting Node 0 Processor 4 APIC 0x1 > > > smpboot: Booting Node 0 Processor 5 APIC 0x3 > > > smpboot: Booting Node 0 Processor 7 APIC 0x7 > > > > > > In 4.18.1, dmesg shows: > > > > > > smpboot: Booting Node 0 Processor 3 APIC 0x6 > > > smpboot: Booting Node 0 Processor 4 APIC 0x1 > > > smpboot: CPU 4 is now offline > > > smpboot: Booting Node 0 Processor 5 APIC 0x3 > > > smpboot: CPU 5 is now offline > > > smpboot: Booting Node 0 Processor 7 APIC 0x7 > > > smpboot: CPU 7 is now offline > > > > > > and I get an "Operation cancelled" error in the shell when trying to online 4, > > > 5, and 7. > > > > > > In 4.18.1, /sys/devices/system/cpu/smt/control says "notsupported". > > > > > > - - - > > > > > > A possible second regression is the following: > > > > > > My CPU normally runs at 3600 MHz. I usually run my CPU at 2800 MHz to keep from > > > overheating under full load (it is a fanless system). I do this by running > > > "echo 1 > /sys/class/thermal/cooling_device5/cur_state", and confirm with "cat > > > /proc/cpuinfo" (shows 2800). > > > > > > This works in 4.18.0 but not in 4.18.1. I get no error from the "echo" command > > > (and the state reads back as "1"), but the CPU remains running at 3600 MHz. > > > > How about Linus's tree at the moment, is it ok there? > > > > thanks, > > > > greg k-h > > > > It also fails in Linus's tree. Seems like this logic is to blame: > > /* > * If SMT was disabled by BIOS, detect it here, after the CPUs have been > * brought online. This ensures the smt/l1tf sysfs entries are consistent > * with reality. cpu_smt_available is set to true during the bringup of non > * boot CPUs when a SMT sibling is detected. Note, this may overwrite > * cpu_smt_control's previous setting. > */ > void __init cpu_smt_check_topology(void) > { > if (!cpu_smt_available) > cpu_smt_control = CPU_SMT_NOT_SUPPORTED; > } > > SMT is enabled in my BIOS, but because I booted with maxcpus=2, the init code > never officially booted any SMT thread yet--just primary threads. I suspect the > line 'cpu_smt_available = true;' in kernel/cpu.c function cpu_smt_allowed() is > never being reached. > > It is then impossible to boot any SMT thread after init is done, since > 'cpu_smt_available' is false. > > The following test patch makes everything work for me on both mainline and > 4.18.1, but we might as well throw out 'cpu_smt_available' altogether then (or > find another way to set it appropriately). Just because we didn't boot any SMT > threads at init shouldn't mean that SMT is disabled by the BIOS. > > --- > > x86/l1tf: Fix booting with low maxcpus=# causes SMT to be disabled > > If maxcpus=# is given on the kernel command line where # is too low for > any SMT CPU (thread) to be booted during init, then the kernel thinks > SMT is disabled by the BIOS. SMT threads are then unable to be manually > brought online later after init. > > Set 'cpu_smt_available' early on in init instead, if > topology_smt_supported() returns true. > > Fixes: 958f338e96f8 ("Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") > Cc: Thomas Gleixner > Signed-off-by: Byron Stanoszek > --- > kernel/cpu.c | 10 ++-------- > 1 file changed, 2 insertions(+), 8 deletions(-) Thomas is out for at least the rest of this week, so it might be a bit before he sees this :( greg k-h