Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2232703ybi; Sun, 28 Jul 2019 04:45:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqznPRCSG5YLZohuqVoqS/+5K4GXV0vvHklQikZjhZKPswn3S5QyUZftCDJ646kx5FScSzW0 X-Received: by 2002:a62:8246:: with SMTP id w67mr32055477pfd.226.1564314314061; Sun, 28 Jul 2019 04:45:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564314314; cv=none; d=google.com; s=arc-20160816; b=iLt1plKtoHKxtUZV6D7Zv29wUDDw9c2wdDd8Eg84kmqTfF+G5k77C7lSep8Kl+8GA1 GOFBTrQDoOYlRqxGzyXQyKXaNVjIFvE22KfNrJBd5t6Z9huHb1ALQWDYdgpaxyi9d4Mq ltZjziSU5aeblitGcaMCHc7zOZ6clvJvffxTi0fLFebxqyoz2fqstfH/kJ5zvPCvDLpX +fd9+wWz/rWwBueJF3sf0SY+vb5VmCtgcz/c5TxQSKQPhgmX1sPm3dy/0Fak+0rpgJTK e6Z2TY4hBvMi75aMgi9BdgeAbf663MF8emiX5htY0E5EAIjJStX0jVwRqfol0kolMV/+ SbHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=qf44Lm6Ndt0XoGZ1L+ZSAACYvmYohYh9reXk0byi8+A=; b=aUlZDGu+Vagi4P8nSbu6rTctU5IHmsfZuMCk1rC739Blle5zlffQTaHItFvm60zrTZ dMoKdB/W4ietlvZIr9DSuw74QGrusZPo3hm9c+pYGKdnYWYIW5d+1seWKsDH1QVHeXGq ipPfsSlmLjGkw3Uf4SHCwysJFY5H0zMlRq4U6ZRygO88CLbdJdGMo26BkJzRb8xDEh1K 2nIYTeLFkhdMj7lrdwi3spNS/AJ+Mn3bKfiMRx5A2HY0ro+jpa9SQIhdilhzQKeaX65I ibc7r67gYtAYQd8Z4koSwacbA7BLZ/GjU4gNb4XM8a60U4iZjdgzBbFovzRR9rpb21XM SuoQ== 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 h6si23384196pll.313.2019.07.28.04.44.58; Sun, 28 Jul 2019 04:45:14 -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 S1726043AbfG1Ln6 (ORCPT + 99 others); Sun, 28 Jul 2019 07:43:58 -0400 Received: from foss.arm.com ([217.140.110.172]:60472 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725983AbfG1Ln6 (ORCPT ); Sun, 28 Jul 2019 07:43:58 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A702F337; Sun, 28 Jul 2019 04:43:57 -0700 (PDT) Received: from [10.163.1.126] (unknown [10.163.1.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F39DE3F71F; Sun, 28 Jul 2019 04:43:50 -0700 (PDT) Subject: Re: [PATCH v9 10/21] mm: Add generic p?d_leaf() macros To: Mark Rutland , Steven Price Cc: linux-mm@kvack.org, Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Dave Hansen , Ingo Molnar , James Morse , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Peter Zijlstra , Thomas Gleixner , Will Deacon , x86@kernel.org, "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Liang, Kan" , Andrew Morton References: <20190722154210.42799-1-steven.price@arm.com> <20190722154210.42799-11-steven.price@arm.com> <20190723094113.GA8085@lakrids.cambridge.arm.com> From: Anshuman Khandual Message-ID: Date: Sun, 28 Jul 2019 17:14:31 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190723094113.GA8085@lakrids.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/23/2019 03:11 PM, Mark Rutland wrote: > On Mon, Jul 22, 2019 at 04:41:59PM +0100, Steven Price wrote: >> Exposing the pud/pgd levels of the page tables to walk_page_range() means >> we may come across the exotic large mappings that come with large areas >> of contiguous memory (such as the kernel's linear map). >> >> For architectures that don't provide all p?d_leaf() macros, provide >> generic do nothing default that are suitable where there cannot be leaf >> pages that that level. >> >> Signed-off-by: Steven Price > > Not a big deal, but it would probably make sense for this to be patch 1 > in the series, given it defines the semantic of p?d_leaf(), and they're > not used until we provide all the architectural implemetnations anyway. Agreed. > > It might also be worth pointing out the reasons for this naming, e.g. > p?d_large() aren't currently generic, and this name minimizes potential > confusion between p?d_{large,huge}(). Agreed. But these fallback also need to first check non-availability of large pages. I am not sure whether CONFIG_HUGETLB_PAGE config being clear indicates that conclusively or not. Being a page table leaf entry has a broader meaning than a large page but that is really not the case today. All leaf entries here are large page entries from MMU perspective. This dependency can definitely be removed when there are other types of leaf entries but for now IMHO it feels bit problematic not to directly associate leaf entries with large pages in config restriction while doing exactly the same.