Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1979887imm; Mon, 3 Sep 2018 14:58:33 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaiUoGkrhpPAfT2M7vsjGuwfdgmnjHNZVDHdlFbBccH20TA0owJHAU74CKmek1XWpP5khQ0 X-Received: by 2002:a17:902:47:: with SMTP id 65-v6mr17930627pla.293.1536011913563; Mon, 03 Sep 2018 14:58:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536011913; cv=none; d=google.com; s=arc-20160816; b=ilz7q4eGvPd75Qy5bbRJp2tOBtr/6eyZBy15xFV6EyWkTeu3jkGcvQcXVbvvRnW/IS 1V2647ZHm71+Cot7sSAo6JYEIVgPw7F/GkfkG59+LYOpgf71TH2dWmzJuaKQmjtDgAg8 +y4PCC+4FiOKi1xiO4Ay6q4b9h+kPjmv7O/KUw4h7IK3B7Rq04/GXeJh+rziK3CX+edG pQiiMWpA323p0tpIjZzLO0Pxg7sUJCsG15Zg4h5Pe+XSFMmtkRKstEIiH50C9bAtwJRa O62mEOMFH6B9rNzYEaHhpCQWTuyYwK1LSXV67pLnbNdDzPa+MWvw5KOfsUayMOPsnzeM zlDA== 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=rF/Vrb8MAcAyxJ5hovtHreFpXPpLWXjdFnWRobNrPuc=; b=BVOPsCoDvdyhZwnbZFmJRP2/cJEkzkZBb3l/1T0BAetw7HwQht4sQmp8UorJ0CLnNm OjRIQt4Wd4J+/UEmYr9jxMJR8GUyVEOcXaimySIaAQ9OU9DfoH07l8FGIe2aA1lX7DQb i5FWrNVU50qft6gsuCYpVUk0msr/9zeLt5TT/2VLLmpR1Ew65JttUR6OZqfzuDEh7YKP ur17+yoJAaS3XQp3bhJyX5GJco4uYsSgd7RqNdbubsFEkIqtBYaPeh8qtNRdbe572PEh FLeI9nRLi0h9457iE989VsXeyyUe1fAnCLa/fcvXx+CTH+HrX14PkDMjPLKdAZDzCSrU l8Ig== 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 205-v6si18688669pgd.271.2018.09.03.14.58.18; Mon, 03 Sep 2018 14:58:33 -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 S1727429AbeIDCTV (ORCPT + 99 others); Mon, 3 Sep 2018 22:19:21 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:55841 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726183AbeIDCTU (ORCPT ); Mon, 3 Sep 2018 22:19:20 -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 1fwwqI-0001eg-TS; Mon, 03 Sep 2018 23:57:07 +0200 Date: Mon, 3 Sep 2018 23:57:03 +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 1/5] x86/mm: avoid redundant checking if pgprot has no change In-Reply-To: <1534814186-37067-2-git-send-email-bin.yang@intel.com> Message-ID: References: <1534814186-37067-1-git-send-email-bin.yang@intel.com> <1534814186-37067-2-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: > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -629,6 +629,22 @@ try_preserve_large_page(pte_t *kpte, unsigned long address, > new_prot = static_protections(req_prot, address, pfn); > > /* > + * The static_protections() is used to check specific protection flags > + * for certain areas of memory. The old pgprot should be checked already > + * when it was applied before. If it's not, then this is a bug in some > + * other code and needs to be fixed there. > + * > + * If new pgprot is same as old pgprot, return directly without any > + * additional checking. The following static_protections() checking is > + * pointless if pgprot has no change. It can avoid the redundant > + * checking and optimize the performance of large page split checking. > + */ > + if (pgprot_val(new_prot) == pgprot_val(old_prot)) { This is actually broken. Assume that for the start address: req_prot != old_prot and new_prot != req_prot and new_prot == old_prot and numpages > number_of_static_protected_pages(address) Then the new check will return with split = NO and the pages after the static protected area won't be updated -> FAIL! IOW, you partially reintroduce the bug which was fixed by adding this check loop. So this is a new optimization check which needs to be: if (pgprot_val(req_prot) == pgprot_val(old_prot)) and that check wants to go above: new_prot = static_protections(req_prot, address, pfn); Both under the assumption that old_prot is correct already. Now the question is whether this assumption can be made. The current code does that already today in case of page splits because it copies the existing pgprot of the large page unmodified over to the new split PTE page. IOW, if the current mapping is incorrect it will stay that way if it's not part of the actually modified range. I'm a bit worried about not having such a check, but if we add that then this should be done under a debug option for performance reasons. The last patch which does the overlap check is equally broken: + /* + * Ensure that the requested pgprot does not violate static protection + * requirements. + */ + new_prot = static_protections(req_prot, address, + numpages << PAGE_SHIFT, pfn); It expands new_prot to the whole range even if the protections only overlap. That should not happen in practice, but we have no checks for that at all. The whole thing needs way more thought in order not to (re)introduce subtle and hard to debug bugs. Thanks, tglx