From nobody Wed Dec 17 15:08:59 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FD78C77B78 for ; Wed, 19 Apr 2023 05:22:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231532AbjDSFWY (ORCPT ); Wed, 19 Apr 2023 01:22:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231128AbjDSFWV (ORCPT ); Wed, 19 Apr 2023 01:22:21 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0E3659D5 for ; Tue, 18 Apr 2023 22:22:20 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id n193so8456026ybf.12 for ; Tue, 18 Apr 2023 22:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681881740; x=1684473740; h=mime-version:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=vsilJRm3n3f0oPJ2h9sspFYqHtbv7ku0fM9SdrcDCj8=; b=hj4EKxmQkVBjeHFrYiX7OIFcERVkkm20q7aY8LG40YNwmqdoPSyqvOdb0/0VfE1HZF 1wxaXil9DYJpM9FfY+3v1j5YdDlMBhRqjOSQqV4mR/oeTrfbP3jWVWO06L2fYMwHFG/W GYfKckQve5I0/GA5Mr0muOMEUQb1Kii27Lg526hjbrkSn0+XQUDEzq92zWBS/wJDbdyb 0l+ZllTmJe+ZeMEplq6HV9LkRdyiO60luNh5CdjNGdHXp6TauzpYRbpE1Ce6e/jbxGQt vhIT6k8BIJJzk6DLkWkrjPkLyIyAnPJx+fHf7SaAjCwZqbdA7ZpgSPBHDfZh5Z0fVBUJ /4Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681881740; x=1684473740; h=mime-version:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vsilJRm3n3f0oPJ2h9sspFYqHtbv7ku0fM9SdrcDCj8=; b=eYYbbgZjvw9lWduyhG68VpAQeDkPhxB0PR8ZWUoPP/8eqyUMSHnjeO6iSpFttuLFsj XMjcvoOmsPrhZJw2sxuF07/kehzHvMGqcn6U3K5kWaRojrKoGyOnNNYIfQsvcuzzHqr1 YqiSv6Ni2UvkYwFFHwBd+p5CQ5cd1YVqLQGjuIh7jxFmVxaIdfX72ChzjL6EuGub4Wli JLMtZRy1L/2cWcX3/f8GJX4cPpkWCQcn5QikZgu8ibPll5yiAYToB71o8gWA9Hjktyi5 fs27ZBEXUUr1B69oZEMG3e2SK3WopOAV4LgEHGy0ziLmuIxKIYf4S+0/viln3/3Xs8Mk ladA== X-Gm-Message-State: AAQBX9cu5fdl79ZOLVW+mK2h7s7pfdKEVOctfaKEtQmrm1D/wAGn77h9 X6+jbsejocX6Klhox318IqFGI/s7ks/GLw+VckTtuQ== X-Google-Smtp-Source: AKy350Z4PF4zy3c1rTsiOTRbkNvu2a0h9Py9+yH8dop+BTUO2eEpHa0CbiPxrZt0Z7LgGEs/pHl/wA== X-Received: by 2002:a25:4987:0:b0:b8f:2d6f:1f0b with SMTP id w129-20020a254987000000b00b8f2d6f1f0bmr21036178yba.49.1681881739920; Tue, 18 Apr 2023 22:22:19 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id j185-20020a8155c2000000b00545a08184fdsm4238243ywb.141.2023.04.18.22.22.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 22:22:19 -0700 (PDT) Date: Tue, 18 Apr 2023 22:22:02 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Andrew Morton cc: Mike Kravetz , Muchun Song , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH next] hugetlb: pte_alloc_huge() to replace huge pte_alloc_map() Message-ID: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Some architectures can have their hugetlb pages down at the lowest PTE level: their huge_pte_alloc() using pte_alloc_map(), but without any following pte_unmap(). Since none of these arches uses CONFIG_HIGHPTE, this is not seen as a problem at present; but would become a problem if forthcoming changes were to add an rcu_read_lock() into pte_offset_map(), with the rcu_read_unlock() expected in pte_unmap(). Similarly in their huge_pte_offset(): pte_offset_kernel() is good enough for that, but it's probably less confusing if we define pte_offset_huge() along with pte_alloc_huge(). Only define them without CONFIG_HIGHPTE: so there would be a build error to signal if ever more work is needed. For ease of development, define these now for 6.4-rc1, ahead of any use: then architectures can integrate patches using them, independent from mm. Signed-off-by: Hugh Dickins Reviewed-by: Mike Kravetz --- include/linux/hugetlb.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -183,6 +183,23 @@ extern struct list_head huge_boot_pages; =20 /* arch callbacks */ =20 +#ifndef CONFIG_HIGHPTE +/* + * pte_offset_huge() and pte_alloc_huge() are helpers for those architectu= res + * which may go down to the lowest PTE level in their huge_pte_offset() and + * huge_pte_alloc(): to avoid reliance on pte_offset_map() without pte_unm= ap(). + */ +static inline pte_t *pte_offset_huge(pmd_t *pmd, unsigned long address) +{ + return pte_offset_kernel(pmd, address); +} +static inline pte_t *pte_alloc_huge(struct mm_struct *mm, pmd_t *pmd, + unsigned long address) +{ + return pte_alloc(mm, pmd) ? NULL : pte_offset_huge(pmd, address); +} +#endif + pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, unsigned long sz); /*