Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp305868rwe; Tue, 18 Apr 2023 22:30:34 -0700 (PDT) X-Google-Smtp-Source: AKy350b6bkbTSPc+1Fct99LxfCEi6mTTyyFhVvwLyCAMVF67WRBIcOwvsIfrvPav9gXLa8eDAmu4 X-Received: by 2002:a05:6a21:78e:b0:f0:942e:873b with SMTP id mg14-20020a056a21078e00b000f0942e873bmr2071609pzb.7.1681882234139; Tue, 18 Apr 2023 22:30:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681882234; cv=none; d=google.com; s=arc-20160816; b=nWw8rf1mY1CC1aOpdKcid3L3WQS4GnRhILy9b3vD+mkkyQ0qzElwx824m4QmseRlJc XlDRUQEXjPJniJc6uxE9JOGMW7SdbAeN7Vo1+J3g0cVlY3/cKgJ9ffADLNOGzVSI+fO+ 1GMciK7RQJd1fqeWeRA3HXSL2gScbMePeP9Mndx8YXyemqVBpcvudK7+GUcFVG5xPuHo uRVbTQ+CrZ0ZPVtwLnZq5p3O5HnO7wWjYzX617vVVybLWyklcYfWKUOxg2VUyHqDEVD+ PYMhvct0Hh94H32pRTOWuf2c2HAcVdcfoqis4jPYgHlEfkNkjJFmfnOkf1EKdUsd/Y/O cYXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=vsilJRm3n3f0oPJ2h9sspFYqHtbv7ku0fM9SdrcDCj8=; b=OlGu92Mo2scdeI4MeVUfzEY5yV23nhajTI5OZ+vrLK/DwbzDp6A7h68VZg++zWqPi7 T2ED+APIxEJIznVVM3eU52kdPKm6OSNGUL6jpya8oe8CdKMiyhyASmsYrCPjko5uF3xt b1/YZKPSOnMug19ZmKBrcy48Yavzd8PaHKOVKvvipiHwOvl6Jv7/eMoHwtO/0JgPI5Zq fkKyfOx8fIBugc8M0B9LypiqNA7WMO4I3/C2SqKlpb0od8xOxhsUal0zUENUppHULqsa YBvce16zpFSzyrRcKayaGT81J9Ff/zRNCXMP/Fnu/61HEn8pP7mDhVk/WfwnfBSObrSf kSXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=hj4EKxmQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i13-20020a63e90d000000b0050bfa82c244si15978074pgh.440.2023.04.18.22.30.21; Tue, 18 Apr 2023 22:30:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=hj4EKxmQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231362AbjDSFWX (ORCPT + 99 others); Wed, 19 Apr 2023 01:22:23 -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-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 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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; /* arch callbacks */ +#ifndef CONFIG_HIGHPTE +/* + * pte_offset_huge() and pte_alloc_huge() are helpers for those architectures + * 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_unmap(). + */ +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); /*