From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01326C433FE for ; Wed, 2 Feb 2022 07:37:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 369AD8D00F1; Wed, 2 Feb 2022 02:37:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3192E8D00DD; Wed, 2 Feb 2022 02:37:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E15A8D00F1; Wed, 2 Feb 2022 02:37:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 00A498D00DD for ; Wed, 2 Feb 2022 02:37:53 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9AD65972F5 for ; Wed, 2 Feb 2022 07:37:53 +0000 (UTC) X-FDA: 79097035626.11.12CE86D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 2834B20002 for ; Wed, 2 Feb 2022 07:37:53 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4526F6178B; Wed, 2 Feb 2022 07:37:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79825C004E1; Wed, 2 Feb 2022 07:37:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643787471; bh=7Zag7dWQmRrl03hXTb84l3LTObjja6xIUoq+LfZuQXk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ttC/UT8kEhBhnoU8XxjcM+p0HX+TJ8ZQD46rgIV95aQ62WZkyTz2SCPAD8aVNNPfd 4y7xCYEmK+ZfPA61pTFl/sPSnTMlkF55i7nwGo9tGjsiiFSX4wcyKiRELSf+Q8mlGJ owSoa28EIL1M7x8JHcOINTehR6vQlheRxUr7IIwBnFyiKIlr80xn1pY4O5KmIWJXDZ 8RyTbYPZQa42Joj4T5iGucj+EvoGd81De984eK0epLrIWjmbwgl7AIGdz0jrDL22GR kYFTRLX7vyfZKTO5TceTnUIfAy/CwPH7+hSedDh48ijxSe8XSXDgT31hzBzgiaXaTu 3wLM+EmzJYSTQ== Date: Wed, 2 Feb 2022 09:37:41 +0200 From: Mike Rapoport To: Christophe Leroy Cc: Anshuman Khandual , "linuxppc-dev@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Paul Mackerras , Catalin Marinas , "sparclinux@vger.kernel.org" , Andrew Morton , Will Deacon , "David S. Miller" , "linux-arm-kernel@lists.infradead.org" , Mike Kravetz Subject: Re: [PATCH] mm: Merge pte_mkhuge() call into arch_make_huge_pte() Message-ID: References: <1643780286-18798-1-git-send-email-anshuman.khandual@arm.com> <76605ef1-f2fe-8682-1eb7-2323f0b9bbaa@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <76605ef1-f2fe-8682-1eb7-2323f0b9bbaa@csgroup.eu> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2834B20002 X-Stat-Signature: 7s5uodq9gy8fsujyqt6g9fn7o5oh9d6e Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="ttC/UT8k"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspam-User: nil X-HE-Tag: 1643787473-78282 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 02, 2022 at 06:25:31AM +0000, Christophe Leroy wrote: >=20 >=20 > Le 02/02/2022 =E0 07:18, Mike Rapoport a =E9crit=A0: > > On Wed, Feb 02, 2022 at 11:08:06AM +0530, Anshuman Khandual wrote: > >> Each call into pte_mkhuge() is invariably followed by arch_make_huge= _pte(). > >> Instead arch_make_huge_pte() can accommodate pte_mkhuge() at the beg= inning. > >> This updates generic fallback stub for arch_make_huge_pte() and avai= lable > >> platforms definitions. This makes huge pte creation much cleaner and= easier > >> to follow. > >=20 > > Won't it break architectures that don't define arch_make_huge_pte()? >=20 > It shouldn't, see below Right, overlooked that. =20 > >> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > >> index d1897a69c540..52c462390aee 100644 > >> --- a/include/linux/hugetlb.h > >> +++ b/include/linux/hugetlb.h > >> @@ -754,7 +754,7 @@ static inline void arch_clear_hugepage_flags(str= uct page *page) { } > >> static inline pte_t arch_make_huge_pte(pte_t entry, unsigned int s= hift, > >> vm_flags_t flags) > >> { > >> - return entry; > >> + return pte_mkhuge(entry); > >> } > >> #endif > >> =20 --=20 Sincerely yours, Mike.