From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-3705854-1516999823-2-2317472497059763591 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.001, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='name', MailFrom='org' X-Spam-charsets: plain='us-ascii' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: stable-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516999822; b=ZVxNHMzzhB4XvIH+5dHNXbbexIj9LpXTAx/Pi8EV196WThE OUBhT4mf2BohVfam6ZrO6BnkWFPRAAc5xDJnglIoj9Gj7mYz+D5M252iQuRj20/K I1/KYpLbefJ834tux4qYclSGfCpYLA9Vqs7zDYu4Bm7JqAyTWMRqeILg4spx69ky z4UzhUvrEAVt/Fnp+upOPu6P7c3G+duf9kn+uhlJipszTVrJBFNZXa7J7aLM3F/o hlKm6OTzBoxV2IUVCsIJUAfMNpzkNJORwbrZozO3lEKSK2eW0HsaSs0QszHQXaH3 ZA/MmOkWYQTOdLiCiYw2Glq7R+EEGHmS1tv8xJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to:sender :list-id; s=arctest; t=1516999822; bh=9HvjpY7PZcEEiGh8EzvjoPlcKF a0hIQa9TGJekDSdsE=; b=InL6Qhjh+/m5NGbAqGDP6CTO69GrSPPm3fWa04nkPo 1FYxLuZ4wS123b6K8kqrBxTixMjzTIB//0wYeK3TyGwXrnl7djHlvKZQRZMmb0XX hUbxyLqbZEFT8hpHrM4f9IamNxt+9fy1s2ZIbDHsJqguTBOzA94kuArCHp1/V65e 86FPwS04pEa5Sk3Ai3QJTcUHk9UqbJT0lEi/xNN2eP2BFrbubaMdW51ZPFLNjpqj ZjaRV5bfsh38OXGmlI6w1tj7/CWJQfMiUgZHIR7XnRw1ZcEdpiHOth7wrJQDkCB9 QaQMK6O3h1SIdHa4ZXz2EBKGijFoLpV9T7GQoXZzS0Sg== ARC-Authentication-Results: i=1; mx3.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b=sBoi0THM x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20150623; dmarc=none (p=none,has-list-id=yes,d=none) header.from=shutemov.name; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=O+ihtGMd; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=shutemov.name header.result=pass header_is_org_domain=yes Authentication-Results: mx3.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b=sBoi0THM x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20150623; dmarc=none (p=none,has-list-id=yes,d=none) header.from=shutemov.name; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=O+ihtGMd; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=shutemov.name header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751408AbeAZUuT (ORCPT ); Fri, 26 Jan 2018 15:50:19 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:37540 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751363AbeAZUuG (ORCPT ); Fri, 26 Jan 2018 15:50:06 -0500 X-Google-Smtp-Source: AH8x2251Mr4pL9IlrSKXxatBP4kuRJJmHeCxUzyglWRf5LX7/ApCPoEv2rZLVv5lgh6MbhuuFkSXgw== Date: Fri, 26 Jan 2018 23:50:03 +0300 From: "Kirill A. Shutemov" To: Andy Lutomirski Cc: Konstantin Khlebnikov , Dave Hansen , X86 ML , Borislav Petkov , Neil Berrington , LKML , stable Subject: Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems Message-ID: <20180126205003.7dpkewl23qn2v5il@node.shutemov.name> References: <346541c56caed61abbe693d7d2742b4a380c5001.1516914529.git.luto@kernel.org> <20180126185143.dx7emh7cq5pbrkxn@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: stable-owner@vger.kernel.org X-Mailing-List: stable@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Fri, Jan 26, 2018 at 11:02:08AM -0800, Andy Lutomirski wrote: > On Fri, Jan 26, 2018 at 10:51 AM, Kirill A. Shutemov > wrote: > > On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote: > >> Neil Berrington reported a double-fault on a VM with 768GB of RAM that > >> uses large amounts of vmalloc space with PTI enabled. > >> > >> The cause is that load_new_mm_cr3() was never fixed to take the > >> 5-level pgd folding code into account, so, on a 4-level kernel, the > >> pgd synchronization logic compiles away to exactly nothing. > > > > Ouch. Sorry for this. > > > >> > >> Interestingly, the problem doesn't trigger with nopti. I assume this > >> is because the kernel is mapped with global pages if we boot with > >> nopti. The sequence of operations when we create a new task is that > >> we first load its mm while still running on the old stack (which > >> crashes if the old stack is unmapped in the new mm unless the TLB > >> saves us), then we call prepare_switch_to(), and then we switch to the > >> new stack. prepare_switch_to() pokes the new stack directly, which > >> will populate the mapping through vmalloc_fault(). I assume that > >> we're getting lucky on non-PTI systems -- the old stack's TLB entry > >> stays alive long enough to make it all the way through > >> prepare_switch_to() and switch_to() so that we make it to a valid > >> stack. > >> > >> Fixes: b50858ce3e2a ("x86/mm/vmalloc: Add 5-level paging support") > >> Cc: stable@vger.kernel.org > >> Reported-and-tested-by: Neil Berrington > >> Signed-off-by: Andy Lutomirski > >> --- > >> arch/x86/mm/tlb.c | 34 +++++++++++++++++++++++++++++----- > >> 1 file changed, 29 insertions(+), 5 deletions(-) > >> > >> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c > >> index a1561957dccb..5bfe61a5e8e3 100644 > >> --- a/arch/x86/mm/tlb.c > >> +++ b/arch/x86/mm/tlb.c > >> @@ -151,6 +151,34 @@ void switch_mm(struct mm_struct *prev, struct mm_struct *next, > >> local_irq_restore(flags); > >> } > >> > >> +static void sync_current_stack_to_mm(struct mm_struct *mm) > >> +{ > >> + unsigned long sp = current_stack_pointer; > >> + pgd_t *pgd = pgd_offset(mm, sp); > >> + > >> + if (CONFIG_PGTABLE_LEVELS > 4) { > > > > Can we have > > > > if (PTRS_PER_P4D > 1) > > > > here instead? This way I wouldn't need to touch the code again for > > boot-time switching support. > > Want to send a patch? I'll send it with the rest of boot-time switching stuff. > (Also, I haven't noticed a patch to fix up the SYSRET checking for > boot-time switching. Have I just missed it?) It's not upstream yet. There are two patches: initial boot-time switching support and optimization on top of it. https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/wip&id=c35fc0af7a4fe9b5369134d7485d95427a0a039b https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/commit/?h=la57/boot-switching/wip&id=fae0e6c3eb253e63532f4ecfa6705aac2c5d710c -- Kirill A. Shutemov