Received: by 2002:a4a:3008:0:0:0:0:0 with SMTP id q8-v6csp3592631oof; Tue, 4 Sep 2018 00:43:22 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbvqFvwR+dzdf9tdoWNckLFdRSpoqatJvdGvrzisO4mR6zQ8qLXvn2lVkUapN4cGLWZ8AOz X-Received: by 2002:a17:902:3c5:: with SMTP id d63-v6mr25876488pld.145.1536047002013; Tue, 04 Sep 2018 00:43:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536047001; cv=none; d=google.com; s=arc-20160816; b=YcA0V+oVZYoAPepsnmKLLuUMg7XHXJ5novJHViH584MdXuPFG1UaPjOum3scj2nx/g nSPeI1ZJ5v+qP0qTKOhCSt9o/rxjyhlEu9T663OIUa4nbjXsS9lNUz8/m2YIPYjmSLwz rUsYK/GuTP1hCTkYBlBR+yIjSrpl1ppAicPUAUz/5wdYtL8HwKZ8HhYgXjzYGTCA0OL4 94qRlQh8dO+jw3EKM2tcNjz2olpuNaG9vPU/7Pr2JSiYNlX2P39DIP/U0pF+bLyEbgAu pkBZt/gpqoy6PZqfkrAuCChX8AAmt/IMKrHp7plw7egL3+g4vuiOweNFEJNSps3xW/8d i4tA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=3bJu+Mu2Hfhc5eLFbyoHBTfAccoVkwtWJtJ1y7t74jg=; b=RltgyHeGSPsApx/kYDkbtaQM46rN2V7AuacvKMRVtoPhDOTDMuYM2CBTvDCph0Lsjk unXLbmnouXS4jOPtSuv3uUryNx5RGsZs1iK8Jcp0xu9obCQZqF+NXoz1KUv3P/s0ehmr Y06GtZyc/vL/8VF6mxIIkQ8IStQre509lom4ww1RoRfJ4Km6WdSFiY/XYXud1a6KChVv CZBNQ4dmDfnrR8qmcv3TeX3Rh4ydfkCpH35lsZ6dE86ff+Iurri3rKVqqB+ntF5WA3Rz Sr4U+a+qh9pnp0F7v8/Qbvgcb9UB5dtHxniQ6PeJhI89e7TylfqqbXXwjrBFRaCC3yPv x7fw== 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 u4-v6si5588247pgr.475.2018.09.04.00.43.06; Tue, 04 Sep 2018 00:43: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726708AbeIDMF7 (ORCPT + 99 others); Tue, 4 Sep 2018 08:05:59 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:56398 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbeIDMF7 (ORCPT ); Tue, 4 Sep 2018 08:05:59 -0400 Received: from p4fea45ac.dip0.t-ipconnect.de ([79.234.69.172] helo=[192.168.0.145]) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fx5yK-0000Rt-Ru; Tue, 04 Sep 2018 09:42:01 +0200 Date: Tue, 4 Sep 2018 09:41:59 +0200 (CEST) From: Thomas Gleixner To: "Yang, Bin" cc: "mingo@kernel.org" , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "Gross, Mark" , "x86@kernel.org" , "Hansen, Dave" Subject: Re: [PATCH v3 5/5] x86/mm: add WARN_ON_ONCE() for wrong large page mapping In-Reply-To: <2ad0ff43ea406005890ad4fcbb7a42da747289d9.camel@intel.com> Message-ID: References: <1534814186-37067-1-git-send-email-bin.yang@intel.com> <1534814186-37067-6-git-send-email-bin.yang@intel.com> <2ad0ff43ea406005890ad4fcbb7a42da747289d9.camel@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 4 Sep 2018, Yang, Bin wrote: > On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote: > > On Tue, 21 Aug 2018, Bin Yang wrote: > > > @@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long address, > > > > > > psize = page_level_size(level); > > > pmask = page_level_mask(level); > > > + addr = address & pmask; > > > > > > /* > > > * Calculate the number of pages, which fit into this large > > > @@ -636,6 +637,12 @@ try_preserve_large_page(pte_t *kpte, unsigned long address, > > > cpa->numpages = numpages; > > > > > > /* > > > + * The old pgprot should not have any protection bit. Otherwise, > > > + * the existing mapping is wrong already. > > > + */ > > > + WARN_ON_ONCE(needs_static_protections(old_prot, addr, psize, old_pfn)); > > > > The check itself is fine, but it just emits a warning and goes on as if > > nothing happened. > > > > We really want to think about a proper way to fix that up without overhead > > for the sane case. > > could we change it as below? I think it should be safe to split large > page if current mapping is wrong already. > > if (needs_static_protections(old_prot, addr, psize, old_pfn)) { > WARN_ON_ONCE(1); > goto out_unlock; > } Sure, but what enforces the static protections on the pages which are not in the modified range of the current CPA call? Nothing. And the above is also wrong because you unconditionally check even if the existing pgprot has the PRESENT bit cleared. Guess what happens. Thanks, tglx