Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1987548imm; Mon, 3 Sep 2018 15:12:04 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZauP5sWNcLYd9puziFsdVNtCs1+nmlOeJNzdwKkdHCf+fQUSK2O9qjzqrXr7ZMrAhySix2 X-Received: by 2002:a17:902:7845:: with SMTP id e5-v6mr30439115pln.197.1536012724002; Mon, 03 Sep 2018 15:12:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536012723; cv=none; d=google.com; s=arc-20160816; b=L+d2OQvjhIpRU0x9k/uF9W528903ydx6ffPh67vaN5yuw/5nI/0hHTPzx9lvtecOxz af2c4tNGqgUZfy9wLpEIlGpGd8QeRLR6MZCwP8PZgcubi6uYS7R4hBSWHnlWOp8OBGSA FOHvG+8W36qfCJUsUt0XBnJZtpT8VN/C/CuP+HoNVTtgw3RrYN5sXYEB6yDVjHFpNSO1 aUrLPSRk1cbaMM58TZqZYR32QWgXgeUzrlbFj8zArVZ05yF4A+3AjLSmpzEGGNRJmKTP MXpvHf2riz+1/soJeu0ryUrkomAJQEmt+VnhQvkXmGeMFeOzy5P6x/kwY5/IUzPva9j7 fdQQ== 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=b/Lbz2C4ege3HKyJBY8i7T+nROC8SNT+gR9Lz8tREd8=; b=CqqrudvKWkp4fhy6EbjG/aE3zLlFEfhI3riivXtAwb1oUN1jNGYZCWxE6HFpzLiqdN gM8fJT9LNVG98L7cqV1dHK6DdLKfvhRL1wzyLst2Vq056bxNmzcJAhxYj5DZYqnxjnI0 j+wj4mGPqOmJV34E9k4TxuaVnvTpNfZgK1WUeYCFh5HXu58QSNuFd62LqZcn3TDc2ple BNV3W1oL+vxQJixbOSvrz3/kpTcTVIbhLeAy5NCk6SaIA3sYQiMszFhavLJwsSY6hd9X JZPa22s6mbLo8WeplxD/15A+dK8DTLBHVjTXO18a9/R0TsmvundIFCegFo8m6xWZ4u7B gqTQ== 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 w68-v6si19958984pfw.308.2018.09.03.15.11.46; Mon, 03 Sep 2018 15:12:03 -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 S1726048AbeIDCcq (ORCPT + 99 others); Mon, 3 Sep 2018 22:32:46 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:55858 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725866AbeIDCcq (ORCPT ); Mon, 3 Sep 2018 22:32:46 -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 1fwx3I-0001of-OV; Tue, 04 Sep 2018 00:10:32 +0200 Date: Tue, 4 Sep 2018 00:10:32 +0200 (CEST) From: Thomas Gleixner To: Bin Yang cc: mingo@kernel.org, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, peterz@infradead.org, dave.hansen@intel.com, mark.gross@intel.com Subject: Re: [PATCH v3 3/5] x86/mm: add help function to check specific protection flags in range In-Reply-To: <1534814186-37067-4-git-send-email-bin.yang@intel.com> Message-ID: References: <1534814186-37067-1-git-send-email-bin.yang@intel.com> <1534814186-37067-4-git-send-email-bin.yang@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, 21 Aug 2018, Bin Yang wrote: > /* > + * static_protections() "forces" page protections for some address > + * ranges. Return true if any part of the address/len range is forced > + * to change from 'prot'. > + */ > +static inline bool > +needs_static_protections(pgprot_t prot, unsigned long address, > + unsigned long len, unsigned long pfn) > +{ > + int i; > + > + address &= PAGE_MASK; > + len = PFN_ALIGN(len); > + for (i = 0; i < (len >> PAGE_SHIFT); i++, address += PAGE_SIZE, pfn++) { > + pgprot_t chk_prot = static_protections(prot, address, pfn); > + > + if (pgprot_val(chk_prot) != pgprot_val(prot)) > + return true; > + } > + > + /* Does static_protections() demand a change ? */ > + return false; > +} ... > if (cpa->force_split) > @@ -660,14 +684,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address, > * static_protection() requires a different pgprot for one of > * the pages in the range we try to preserve: > */ > - pfn = old_pfn; > - for (i = 0; i < (psize >> PAGE_SHIFT); i++, addr += PAGE_SIZE, pfn++) { > - pgprot_t chk_prot = static_protections(req_prot, addr, pfn); > - > - if (pgprot_val(chk_prot) != pgprot_val(new_prot)) > - goto out_unlock; > - } > - > + if (needs_static_protections(new_prot, addr, psize, old_pfn)) > + goto out_unlock; This is not the same. The existing code does: new_prot = static_protections(req_prot, address, pfn); which is the protection updated pgprot for the base of the address range which should be modified. The loop does: chk_prot = static_protections(req_prot, addr, pfn); if (chk_prot != new_prot) goto split; Now mapping your new function back and then the loop becomes: chk_prot = static_protections(new_prot, addr, pfn); if (chk_prot != new_prot) goto split; which is broken in case that after the initial static protections invocation new_prot = static_protections(req_prot, address, pfn); the result is: new_prot != req_prot and in the loop new_prot is valid for _ALL_ pages in the large page because the static protection which got applied for the first address can be applied to the complete range, i.e. new_prot it is not further modified by static_protections() for any page. That again can cause wrong large page preservations. Thanks, tglx