Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2780996imm; Tue, 4 Sep 2018 09:54:02 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZGzxZCGxWuWhl8nt+tv/DS4MJ3HIUjJ6SL6VicxXTet8eB19V/RMF3AHefPp62w5TyLY+c X-Received: by 2002:a62:34c4:: with SMTP id b187-v6mr35337286pfa.15.1536080042573; Tue, 04 Sep 2018 09:54:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536080042; cv=none; d=google.com; s=arc-20160816; b=vcos4hBMiR9FH5YkORGHJrx/08t+rGNLVooQ1RvzEHFJXoscCec31aj585JZlBDwa1 CGyCGZ7oS7rEc7nNLZnAKAgGdlPWBv1d+GdATZwzkhAWRQLwA4AL7FNl9tpN9t3Hs2ZQ tYV8vGyLYWPdGam5Ms+tD9e/XROZwmBRX5SzGjr+zdtfFK4UZ9iw7KRVPlJylRKIZvg3 Q3L7wxl58FUaizF0mvZe0Qq828qWrhna7EwAcguKkEuSyeQpEmlnOxaWq1mzADNyrgEb oX9K88pAJUErlNUK1qNQ/LhEBhHW70PxTnPXEC786fNnhoCnV7gj/RDhVhPk8irOlgzu AXgw== 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=rTUIcPYFEgujNRznLx5D0vOjhFVYXwESEgB4obKcKtk=; b=s6inzDyv77KoaeTAtNe1SdjHuIq9Bet2lvaxGcu9z6LLwdNoiABxjoFbSotzVtxcz8 7yHooeSRNCgwNVv2JVAawjK/8e4hIH3qGOkJVL30kiNg4+gJC0PnFTyQO9w16QVIP6uu k7v1bWAWhlfm1l40Q5i7oyvpz52wHI9utcvm0F0e1z9z3ocQGKWaIls/H6OgdFFtmfPQ 3BXBdNBQtYNZnMRk1liwBh4VEpofME2ssgxC6To3MMWPqhn3Gs1At2v+/A2RsCv2Kv3Q JD5wNa9/cImdSFS+7RguYFYOuVw3+i4IwtUGgdFbA0nOFegab19tHvyEDzIFxpgYe1dS rKFw== 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 j21-v6si20761064pgl.8.2018.09.04.09.53.47; Tue, 04 Sep 2018 09:54:02 -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 S1727645AbeIDVSd (ORCPT + 99 others); Tue, 4 Sep 2018 17:18:33 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:57565 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726167AbeIDVSd (ORCPT ); Tue, 4 Sep 2018 17:18:33 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fxEZ8-0002di-8V; Tue, 04 Sep 2018 18:52:34 +0200 Date: Tue, 4 Sep 2018 18:52:33 +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: 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 4 Sep 2018, Thomas Gleixner wrote: > 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. I looked deeper into that. For the PMD split it's rather trivial to do, but a PUD split would require a horrible pile of changes as we'd have to remove the protections from the new PMD first, go all the way back and rescan the new PMDs whether they need to be split up further. But that needs a lot of refactoring and I'm not sure if it's worth the trouble right now. As we haven't cared about that since CPA got introduced, I think we just do the consistency check and warn. That's better what we have now and when it ever triggers revisit it. Thanks, tglx