From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-727558-1516916971-2-8116175118897024118 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.25, ME_NOAUTH 0.01, 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='com', MailFrom='org' X-Spam-charsets: plain='utf-8' 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=1516916970; b=Wdy8CcONp39FM92NmUMZkMPMZ22twGkhic6MAX/g1qIrlY5 nvu6VajJkR+uNGB/DTG70Nu6/jTzkvJUlT+/jigpgIXuG3YjWxuCAGZhAy247+yv 84ttY9nvQFh0YhrEa6lG9KcWrIR4xeryrEh/BqY+K/bVrdstOUFuupP7k2SMiVsy a840kskMYDwK3WZxtXrHMhRmQMyO72bjnJbww99zl3Yi8twaV5x/wXRhSoYKrPwt G/KNAo2yLmiUWfBMmK9qaQwlywfb9rvTXNmjfIdC84HfVSjhtmZ6/BFpq2nMnAr+ nTyYy4dsXm7D9GVeXuTFIz5z1fyepk+vmpuyHcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=subject:to:references:cc:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding:sender:list-id; s=arctest; t= 1516916970; bh=iH3Nr+iOZX0SKp0b6sMTFELT1nagNDElzYziulf2v54=; b=k GawZFzQvhJ0WQpS1x1emKOmM0ZVrTRq4LE96xRG3JkjCnd+AMFw2uVGhcaIj0SWU tgNyq5fz+dDsxfaR+r7TdoD7qn7X1rpCA3d2aq62jSnar9JfKeSThkykVJtS6TIo /Bv5qjyZDq5tgKBlucSgE/HywDpqx5dLIF6zCnoheF5qMpkp8cdGfbgCIEVuHPlu h07Ao0Kga7vJ7YCNEjJG0gcwqYgodbKYyBl0lxNuso2+N/yUToZ9tUgWe6god7Az dIALdHgmLsu/vEy0A5e0jP6PVFw1n4kTu15QKMFPfyvL4yIpXzqcLpWbSIkAtzPg 7tieqdDH7b/ivxs+1D+mA== ARC-Authentication-Results: i=1; mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=intel.com; 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-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=intel.com header.result=pass header_is_org_domain=yes Authentication-Results: mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=intel.com; 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-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=intel.com header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751187AbeAYVt2 (ORCPT ); Thu, 25 Jan 2018 16:49:28 -0500 Received: from mga06.intel.com ([134.134.136.31]:50063 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751174AbeAYVt2 (ORCPT ); Thu, 25 Jan 2018 16:49:28 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,413,1511856000"; d="scan'208";a="169184231" Subject: Re: [PATCH v2 1/2] x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems To: Andy Lutomirski , Konstantin Khlebnikov , X86 ML , Borislav Petkov References: <346541c56caed61abbe693d7d2742b4a380c5001.1516914529.git.luto@kernel.org> Cc: Neil Berrington , LKML , stable@vger.kernel.org, "Kirill A. Shutemov" From: Dave Hansen Message-ID: Date: Thu, 25 Jan 2018 13:49:25 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <346541c56caed61abbe693d7d2742b4a380c5001.1516914529.git.luto@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 01/25/2018 01:12 PM, 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. You don't mention it, but we can normally handle vmalloc() faults in the kernel that are due to unsynchronized page tables. The thing that kills us here is that we have an unmapped stack and we try to use that stack when entering the page fault handler, which double faults. The double fault handler gets a new stack and saves us enough to get an oops out. Right? > +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) { > + if (unlikely(pgd_none(*pgd))) { > + pgd_t *pgd_ref = pgd_offset_k(sp); > + > + set_pgd(pgd, *pgd_ref); > + } > + } else { > + /* > + * "pgd" is faked. The top level entries are "p4d"s, so sync > + * the p4d. This compiles to approximately the same code as > + * the 5-level case. > + */ > + p4d_t *p4d = p4d_offset(pgd, sp); > + > + if (unlikely(p4d_none(*p4d))) { > + pgd_t *pgd_ref = pgd_offset_k(sp); > + p4d_t *p4d_ref = p4d_offset(pgd_ref, sp); > + > + set_p4d(p4d, *p4d_ref); > + } > + } > +} We keep having to add these. It seems like a real deficiency in the mechanism that we're using for pgd folding. Can't we get a warning or something when we try to do a set_pgd() that's (silently) not doing anything? This exact same pattern bit me more than once with the KPTI/KAISER patches.