Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2045879imm; Mon, 16 Jul 2018 00:50:11 -0700 (PDT) X-Google-Smtp-Source: AAOMgpektuRyI7YJoyYBuVLBqQOLedXiqvEaByXnT20Ym3NGXtJlYtN6RVAZf86Qljq7LeLO6ejW X-Received: by 2002:a63:b40e:: with SMTP id s14-v6mr14818111pgf.9.1531727410978; Mon, 16 Jul 2018 00:50:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531727410; cv=none; d=google.com; s=arc-20160816; b=NxWxYOKgB7cvx34K8w4OQ9vn2Uv8FMOm6X7l9qduD6mwdNbAsH7QXxO4ooBezw8GUr WYe9OZ5QRGn1vrL++r2Dvv6nchoz23ABEONngHhkGhWjFHqLUUA4BAooQfZrdZT+bh0m l0NNemyfkFH3ZOsFELgYZh6QACqL+eUxY0nkHqw352+qFUWGfuQ4TH3fePbHg8Ym/Chv 8EqOAJ8HsOZ8yrwIVD09GXNHfphGXwKre8iVtE7rQFQ1L44zZeP889aEuisHD+5tXVIN nT8jbCHoSImNxasXorJ7yzbO76ZxOYuLh18u8m3R+4a7HaRzioEGwB9I4sZGqDW+S0Xu B5jg== 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=X4wy2Em01GZQ6StAyTTxtP21ej2vB82QCPj49udeHAM=; b=dk05FM2Rpw74DkqmQMXA5mlaonK5TO0DMzsbwA1LOhc9y97x8O4M3lny2di4710YJu H5cxJ4ZG81wINjuwF55cHTs1frfCzf8KhSe7UtI/6quA8nycL5x13QOCSkBwJ/m7KsBm /2n9sq5Q97V0cxPr2q023MjPwuTc5N8NNf24dwf4VVsnz5sgNBvd+xk5QddqaekYF2nV 8BsQC6uPzT3V/ldExTh49GHXMv8FQbJYN6u2QPcE0XYotnno0FtAh2zUjC1ajyKLLl3i TuoNqx9/y7MZ2hChcQdsN8nnu4ZRSSi2qBztsNVzJOqAmQ/0TETOTj67bWB61ML9EzWF o0nw== 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 m141-v6si33250897pfd.310.2018.07.16.00.49.56; Mon, 16 Jul 2018 00:50:10 -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 S2389633AbeGPIOh (ORCPT + 99 others); Mon, 16 Jul 2018 04:14:37 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:51126 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388375AbeGPIOh (ORCPT ); Mon, 16 Jul 2018 04:14:37 -0400 Received: from p4fea5a5a.dip0.t-ipconnect.de ([79.234.90.90] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1feyFA-0006yX-Ca; Mon, 16 Jul 2018 09:48:28 +0200 Date: Mon, 16 Jul 2018 09:48:28 +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] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr In-Reply-To: <6957364e872792c9cc310cf4928ae90771f2b69a.camel@intel.com> Message-ID: References: <1530180340-18593-1-git-send-email-bin.yang@intel.com> <0131cecd5d0456c2a109f4b8bdbfe558389671dd.camel@intel.com> <3224aae1d09788aba687fd7bd9e088f233016fc8.camel@intel.com> <34a76fad5c43c11ce8ceb491537b453d8053bdb2.camel@intel.com> <6957364e872792c9cc310cf4928ae90771f2b69a.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, 10 Jul 2018, Yang, Bin wrote: > > + * FIXME: > > + * 1) Make this yell loudly if something tries to set a full > > + * large page to something which is not allowed. > > I am trying to work out a patch based on your sample code and > comments. > I do not understand here why it needs to yell loudly if set a full > large page to something which is not allowed. It can split the large > page to 4K-pages finally. And static_protection() will also be called > for 4K-page change. Why not just add warning if 4K-page change is not > allowed? Think about it. If there is a large page which contains an area which requires a different mapping that the one which the large page provides, then something went wrong _before_ this code is called. Thanks, tglx