Received: by 10.213.65.68 with SMTP id h4csp1071267imn; Fri, 6 Apr 2018 14:05:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx499mHDQz6frvIgyrEVCq89l90jpripocpyb+nrv1aM1OqMIoBhIDrJcSAewhvsdzSPckjo6 X-Received: by 2002:a17:902:322:: with SMTP id 31-v6mr29022517pld.122.1523048714944; Fri, 06 Apr 2018 14:05:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523048714; cv=none; d=google.com; s=arc-20160816; b=kGvvuN49eebQ81UAE8ni0LDaWFjPe8le0sG32HmaueniIVRNeri5k91LZRUZJ85c0z Ym5PrAsvZxagJ1/dsqu27WQtn7Y/WzbrKfbV/J+mSdS5ba8AsCASYf/CwLjOOeQwu/u3 lV59ig4jLjRu08yIOow8s8N1n/DdKwJ0ABGPAA9Ji0WpxTem5e0g7tKhcBvU6Pu+vJ/G 45yKEWQBeAkGQsVAU6lUMSnxsBotmJb9ZTspMKxSTGEVJHNFurjjMuo8ul8PtX6G8w1F CKYwGNukZKaieNJ/6CZ4R2IsBZ4aGXM9Jwn2RxMeuJJVkd03UZcvHiVuEokfOmwNZejc 1Nkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:in-reply-to:references:date :from:cc:to:subject:arc-authentication-results; bh=mHXVZuAqA8m/4CkyIVnvTAjgNTt0oadsR55PQaZjHCM=; b=037zQSUFywN+Ma82iXsrWZpQN35JEJfJ54rr3rmuPmL9F3J3OzQz0kDuI/ajlYtqW2 /qiijsObnfC7u6INarX4d6640k8FxClRilo7X/d7VFk6xTtsGnd0w9K8wzrfAXD0898o 4Gz43HHg5DMmRP8iqc91PTgUKEPH65zhgzIm9qcsgQ+C3puReJnS93whfs4GAHkJzqnk jV7E4qDlm4ywGpCpRjiBu9+KBEu8ClyuaY0ftG3jmc7kWoPtWMPWSNdNKcPjweOFFCSu n0cH2MLr5tT45t4fAFHsVLwdExl3Pwq/vazvOeyFVUJwG7fgAdeCZ+Qg30cHPZnPMRPu 7LOw== 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 f91-v6si9160470plb.178.2018.04.06.14.04.37; Fri, 06 Apr 2018 14:05:14 -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 S1751981AbeDFU6C (ORCPT + 99 others); Fri, 6 Apr 2018 16:58:02 -0400 Received: from mga06.intel.com ([134.134.136.31]:45325 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751447AbeDFU6B (ORCPT ); Fri, 6 Apr 2018 16:58:01 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 13:58:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,416,1517904000"; d="scan'208";a="44757809" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.39.119]) by fmsmga001.fm.intel.com with ESMTP; 06 Apr 2018 13:58:00 -0700 Subject: [PATCH 02/11] x86/mm: undo double _PAGE_PSE clearing To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Dave Hansen , aarcange@redhat.com, luto@kernel.org, torvalds@linux-foundation.org, keescook@google.com, hughd@google.com, jgross@suse.com, x86@kernel.org, namit@vmware.com From: Dave Hansen Date: Fri, 06 Apr 2018 13:55:04 -0700 References: <20180406205501.24A1A4E7@viggo.jf.intel.com> In-Reply-To: <20180406205501.24A1A4E7@viggo.jf.intel.com> Message-Id: <20180406205504.9B0F44A9@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Hansen When clearing _PAGE_PRESENT on a huge page, we need to be careful to also clear _PAGE_PSE, otherwise it might still get confused for a valid large page table entry. We do that near the spot where we *set* _PAGE_PSE. That's fine, but it's unnecessary. pgprot_large_2_4k() already did it. BTW, I also noticed that pgprot_large_2_4k() and pgprot_4k_2_large() are not symmetric. pgprot_large_2_4k() clears _PAGE_PSE (because it is aliased to _PAGE_PAT) but pgprot_4k_2_large() does not put _PAGE_PSE back. Bummer. Also, add some comments and change "promote" to "move". "Promote" seems an odd word to move when we are logically moving a bit to a lower bit position. Also add an extra line return to make it clear to which line the comment applies. Signed-off-by: Dave Hansen Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Kees Cook Cc: Hugh Dickins Cc: Juergen Gross Cc: x86@kernel.org Cc: Nadav Amit --- b/arch/x86/mm/pageattr.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff -puN arch/x86/mm/pageattr.c~kpti-undo-double-_PAGE_PSE-clear arch/x86/mm/pageattr.c --- a/arch/x86/mm/pageattr.c~kpti-undo-double-_PAGE_PSE-clear 2018-04-06 10:47:54.193796129 -0700 +++ b/arch/x86/mm/pageattr.c 2018-04-06 10:47:54.197796129 -0700 @@ -583,6 +583,7 @@ try_preserve_large_page(pte_t *kpte, uns * up accordingly. */ old_pte = *kpte; + /* Clear PSE (aka _PAGE_PAT) and move PAT bit to correct position */ req_prot = pgprot_large_2_4k(old_prot); pgprot_val(req_prot) &= ~pgprot_val(cpa->mask_clr); @@ -597,8 +598,6 @@ try_preserve_large_page(pte_t *kpte, uns req_prot = pgprot_clear_protnone_bits(req_prot); if (pgprot_val(req_prot) & _PAGE_PRESENT) pgprot_val(req_prot) |= _PAGE_PSE; - else - pgprot_val(req_prot) &= ~_PAGE_PSE; req_prot = canon_pgprot(req_prot); /* @@ -684,8 +683,12 @@ __split_large_page(struct cpa_data *cpa, switch (level) { case PG_LEVEL_2M: ref_prot = pmd_pgprot(*(pmd_t *)kpte); - /* clear PSE and promote PAT bit to correct position */ + /* + * Clear PSE (aka _PAGE_PAT) and move + * PAT bit to correct position. + */ ref_prot = pgprot_large_2_4k(ref_prot); + ref_pfn = pmd_pfn(*(pmd_t *)kpte); break; _