From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:59150 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726092AbgDZDB2 (ORCPT ); Sat, 25 Apr 2020 23:01:28 -0400 Date: Sat, 25 Apr 2020 20:01:24 -0700 From: Andrew Morton Subject: Re: [PATCH 3/3] mm/hugetlb: Introduce HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS Message-Id: <20200425200124.20d0c75fcaef05d062d3667c@linux-foundation.org> In-Reply-To: <87d37591-caa2-b82b-392a-3a29b2c7e9a6@arm.com> References: <1586864670-21799-1-git-send-email-anshuman.khandual@arm.com> <1586864670-21799-4-git-send-email-anshuman.khandual@arm.com> <20200425175511.7a68efb5e2f4436fe0328c1d@linux-foundation.org> <87d37591-caa2-b82b-392a-3a29b2c7e9a6@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-s390-owner@vger.kernel.org List-ID: To: Anshuman Khandual Cc: linux-mm@kvack.org, Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Mike Kravetz , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org On Sun, 26 Apr 2020 08:13:17 +0530 Anshuman Khandual wrote: > > > On 04/26/2020 06:25 AM, Andrew Morton wrote: > > On Tue, 14 Apr 2020 17:14:30 +0530 Anshuman Khandual wrote: > > > >> There are multiple similar definitions for arch_clear_hugepage_flags() on > >> various platforms. This introduces HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS for those > >> platforms that need to define their own arch_clear_hugepage_flags() while > >> also providing a generic fallback definition for others to use. This help > >> reduce code duplication. > >> > >> ... > >> > >> --- a/include/linux/hugetlb.h > >> +++ b/include/linux/hugetlb.h > >> @@ -544,6 +544,10 @@ static inline int is_hugepage_only_range(struct mm_struct *mm, > >> } > >> #endif > >> > >> +#ifndef HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS > >> +static inline void arch_clear_hugepage_flags(struct page *page) { } > >> +#endif > >> + > >> #ifndef arch_make_huge_pte > >> static inline pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma, > >> struct page *page, int writable) > > > > This is the rather old-school way of doing it. The Linus-suggested way is > > > > #ifndef arch_clear_hugepage_flags > > static inline void arch_clear_hugepage_flags(struct page *page) > > { > > } > > #define arch_clear_hugepage_flags arch_clear_hugepage_flags > > Do we need that above line here ? Is not that implicit. It depends if other header files want to test whether arch_clear_hugepage_flags is already defined. If the header heorarchy is well-defined and working properly, they shouldn't need to, because we're reliably indluding the relevant arch header before (or early within) include/linux/hugetlb.h. It would be nice if #define arch_clear_hugepage_flags arch_clear_hugepage_flags #define arch_clear_hugepage_flags arch_clear_hugepage_flags were to generate an compiler error but it doesn't. If it did we could detect these incorrect inclusion orders. > > #endif > > > > And the various arch headers do > > > > static inline void arch_clear_hugepage_flags(struct page *page) > > { > > > > } > > #define arch_clear_hugepage_flags arch_clear_hugepage_flags > > > > It's a small difference - mainly to avoid adding two variables to the > > overall namespace where one would do. > > Understood, will change and resend. That's OK - I've queued up that fix.