Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp139929ybi; Thu, 30 May 2019 22:17:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqyf8OoBGiueV7fTQujcaBsq9kHZstx2J2cF8JYelfRM/nAVCGtmIlcOhKbHsJ8GSrZInabP X-Received: by 2002:a63:eb55:: with SMTP id b21mr6865271pgk.67.1559279841942; Thu, 30 May 2019 22:17:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559279841; cv=none; d=google.com; s=arc-20160816; b=vWtmOf9mhhxxippmBY+8HeO1HV/tYDIE/Gxwkq1BgeSPkHcTXwa0fAUBUvWCBWv7yq vwaYJw2EBmtHK8RUeoi5FJe6abCfTRoBIrk/F5Y57zlWTgKK+hPGlCt2T04XhhR+IAVu TYPJxI3D1mg72ouSnaRyOjL7vXVdcz5a+o0ImI1jzHJHYMQK9JlGF4fcx7Imi+P9LwA6 lFK3l8ZzPdQpKffEkD/DoSDzFgCcres72wOx4fUMcVpYYZtcVYNK1OQUIQgObty7XU6A eqIKTSAO9KVKJrQxLMl7nK/dRfqqVLfzfQ8cwpV/sjM0mec0LEmNS5IQNSJbSEjtczIQ VMcw== 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; bh=NpdFeQ76viEUhuxVk13gib0Sd6wC7FIMGoCbu4gpo1Y=; b=v7+vSG9qTQhTJxudgnqwA1URp5AwY/V47DVJT8t1vSkaz3VGzZDkJmg+wqwr7jl4OL TVbC3ya7X3Vt3/GJ4IAiK/s3xikKPloF47zsM/drBSZFKYB1L6ccjSD8UwSggyLBnhSX yvFNcfSwOyl9MJ/sbaBnxmux5fs7ZKL6b00926g1fo+gOudOXZiw8hSYPBfYFvn4zaof kgV8vzUFEocwdbbOOZgaij9X+2mNYc8xvCUA4bfmwgzd9fDvPIkyJBe8AoeZigElYV2L 0i6xDDKy/HGx4YpJ4g0QNW9wu74Hksz2vRjYsX1w6RGp4go2xIEnbn0VcjcOnhTTWa2/ id9g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gn11si4625716plb.119.2019.05.30.22.17.05; Thu, 30 May 2019 22:17:21 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726723AbfEaFPC (ORCPT + 99 others); Fri, 31 May 2019 01:15:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33948 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725955AbfEaFPC (ORCPT ); Fri, 31 May 2019 01:15:02 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8824D30832C2; Fri, 31 May 2019 05:15:01 +0000 (UTC) Received: from treble (ovpn-124-142.rdu2.redhat.com [10.10.124.142]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB2EA60CA7; Fri, 31 May 2019 05:14:58 +0000 (UTC) Date: Fri, 31 May 2019 00:14:56 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: "Rafael J. Wysocki" , Thomas Gleixner , the arch/x86 maintainers , "Rafael J. Wysocki" , Pavel Machek , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Peter Zijlstra , Linux PM , Linux Kernel Mailing List , Andy Lutomirski Subject: Re: [PATCH v4] x86/power: Fix 'nosmt' vs. hibernation triple fault during resume Message-ID: <20190531051456.fzkvn62qlkf6wqra@treble> References: <20190530233804.syv4brpe3ndslyvo@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Fri, 31 May 2019 05:15:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 31, 2019 at 01:42:02AM +0200, Jiri Kosina wrote: > On Thu, 30 May 2019, Josh Poimboeuf wrote: > > > > > Reviewed-by: Thomas Gleixner > > > > > > Yes, it is, thanks! > > > > I still think changing monitor/mwait to use a fixmap address would be a > > much cleaner way to fix this. I can try to work up a patch tomorrow. > > I disagree with that from the backwards compatibility point of view. > > I personally am quite frequently using differnet combinations of > resumer/resumee kernels, and I've never been biten by it so far. I'd guess > I am not the only one. > Fixmap sort of breaks that invariant. Right now there is no backwards compatibility because nosmt resume is already broken. For "future" backwards compatibility we could just define a hard-coded reserved fixmap page address, adjacent to the vsyscall reserved address. Something like this (not yet tested)? Maybe we could also remove the resume_play_dead() hack? diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h index 9da8cccdf3fb..1c328624162c 100644 --- a/arch/x86/include/asm/fixmap.h +++ b/arch/x86/include/asm/fixmap.h @@ -80,6 +80,7 @@ enum fixed_addresses { #ifdef CONFIG_X86_VSYSCALL_EMULATION VSYSCALL_PAGE = (FIXADDR_TOP - VSYSCALL_ADDR) >> PAGE_SHIFT, #endif + FIX_MWAIT = (FIXADDR_TOP - VSYSCALL_ADDR - 1) >> PAGE_SHIFT, #endif FIX_DBGP_BASE, FIX_EARLYCON_MEM_BASE, diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 73e69aaaa117..9804fbe25d03 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -108,6 +108,8 @@ int __read_mostly __max_smt_threads = 1; /* Flag to indicate if a complete sched domain rebuild is required */ bool x86_topology_update; +static char __mwait_page[PAGE_SIZE]; + int arch_update_cpu_topology(void) { int retval = x86_topology_update; @@ -1319,6 +1321,8 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) smp_quirk_init_udelay(); speculative_store_bypass_ht_init(); + + set_fixmap(FIX_MWAIT, __pa_symbol(&__mwait_page)); } void arch_enable_nonboot_cpus_begin(void) @@ -1631,11 +1635,12 @@ static inline void mwait_play_dead(void) } /* - * This should be a memory location in a cache line which is - * unlikely to be touched by other processors. The actual - * content is immaterial as it is not actually modified in any way. + * This memory location is never actually written to. It's mapped at a + * reserved fixmap address to ensure the monitored address remains + * valid across a hibernation resume operation. Otherwise a triple + * fault can occur. */ - mwait_ptr = ¤t_thread_info()->flags; + mwait_ptr = (void *)fix_to_virt(FIX_MWAIT); wbinvd();