From patchwork Wed Apr 19 05:22:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hugh Dickins X-Patchwork-Id: 13216378 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 E39EEC77B73 for ; Wed, 19 Apr 2023 05:22:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BFE48E0002; Wed, 19 Apr 2023 01:22:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1701E8E0001; Wed, 19 Apr 2023 01:22:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05F898E0002; Wed, 19 Apr 2023 01:22:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id EBBCC8E0001 for ; Wed, 19 Apr 2023 01:22:22 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AB47940145 for ; Wed, 19 Apr 2023 05:22:22 +0000 (UTC) X-FDA: 80696994924.21.15A62CF Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf22.hostedemail.com (Postfix) with ESMTP id D7319C000F for ; Wed, 19 Apr 2023 05:22:20 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=hj4EKxmQ; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681881740; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=vsilJRm3n3f0oPJ2h9sspFYqHtbv7ku0fM9SdrcDCj8=; b=uQlMgjA+A/A2EzhBqnBfn206lZKRvs5tUQ7i/Rrip3ZgUeCWrd5pUKokVSg1VzW2zAKoIf +g1thqC02o7sw4HiZMivezq1BVNnK0MfwCASpYvC1OedQYHUjsOvcmgdjpZ/BnWz1+rM7A 18/TjdIJYOBBoJ8Mu17EHkuFpfdm/r0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=hj4EKxmQ; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681881740; a=rsa-sha256; cv=none; b=NO4fWz5lGGke5OPTMJHByVwovO0mS+c6biRFFx6IUrijlrGpu74lYHkHwpqS2VRZ2nwUzD V4JG1gSxWTFMZgwCnwBLUJ0WwNfp+DOBW6lkOcrESXy/cvAeGxwiQsN9QoZUGxchpqV0Z+ 9Yr2t1UMYvgSM9NXnhAIyISs6oaqtTU= Received: by mail-yb1-f182.google.com with SMTP id a11so8579715ybm.3 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=AF2DvRupFdq8jQq4X2K1IAEfK2zplIPt6jTzc6FltKQp4tThcWJbMKFaBjvUD7JUAB D6hWES6GMRCdHTkOHR9R6o2vY1rRj1jHX61/aJyZviiOMyLwC9JQCWROC6X4FN+woplK qIE/KedYJHA/u5prwsbJzcCDN9Leq/H4tpQr5SbTSb+DW+aenaRD7/dLtZ04k8IcTgxq ndnnPrBN+nHviJLJBsz3d+cwsWem9OZwNfvHgGTd4+K7IB+2Xqxk9Ra1XeUfP7Q9XwYI KLEO/lmO7ZDv3m4X0Yio0qLXAxc9gjRDuNgV/g/OPSH2yuilOIdw1HM2H6V236t0EzV5 OWqA== X-Gm-Message-State: AAQBX9eZzy0BbExnPXixFh09Xg+xfOjwvTMJEM0cmZS9Gyyv027MRZiO d/rAOE89lueYjxXn1/XZf2N2hw== 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 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D7319C000F X-Rspam-User: X-Stat-Signature: q5rg1tfq9txwy4c1xtueb83kzyu8uhso X-HE-Tag: 1681881740-425092 X-HE-Meta: U2FsdGVkX1+VUCJlNcZ5sqLXW5cZwcYOgOOzwPaj0lHBPezrE+r3qqp4HBh/9h02Ve3lu8UGUzlq/dhua6oSr3EEK59Pqp3I56KhdfGh8oP/T8Fh3qAmZolk4upVbS/RpmwM4Rjz+Nv5yn+Nt+waWVREaLM1CxSw0MzNMWTG1uHZj5yd3mpREQUQKtcSKuJVeJmZwkwvuGlzwiC9rroswBmId9lMzaMKCniykJ/nnRMOj5QMsWiemXwqxoDaxFXmTkRGEjf3KLNWwVbyJIV73+r0+ASaS6GHNWVVJuVaQ7Hgu6wOvEagJEcN3xC4Ry4Huc2ffsKz5aZ0WI4LCFPnMysneFKaotE5TA6zBlOyFdOk5mRQO7PyapJlgBx0hKjfFGqi0kvBg81H/3HctOcdWdWEzwb6fGcPkVlRAMUCMMIdQlYaqxJ8rTEF/euqeimR41Z4VJ2/kamOTR1iMT6f/4CAEAgagzrB3SPKMRD55+R3m3N08t6Vq18O81q0zYQ1ouDJdiGqZ0nS8bWWW9xRupJoAPfhsnL8SaZyFE+i/Oy+GBZSbvZno4J4vVoL4O88070IpqtNByy00DSBuSr4qPDrXafldoYpJJoz+Gp7rL6VfBF/0WdX6K/9ytPJ4tVdRVm3wSTh//pXjLn3z35qzGBvmq8InVnztNOki3AjI0PkZprpc7j6oSVLnArB/0FLrbfL3KqiPzXGDEoMvcdCI9iI6wsK7V8/ROdiODjVlU1UCpEyQPFMNFC3/D6oVX1vUyIOmstEUxjRC4AWMz/zkVywuYydr3D696Fjjm6na7VRQx1oothGQxR27Pe2bWnbU5kqVRXQsJ0qIuIz50CjERBOj2DLlLy30umvJdIf+pxrIinQ0iNY6A38oJ1soScaBkXHrX9QEwjApxc1PuxtATVDUtBj/bSUWnV2Yurm9ugPxuXdTO1semVB4ZF7LSdFKkzM+6t/uAGWQDKhVMz rvwPcVtC intuvk+YZOXFkKkLxeuveg3+/ZgffD1OojQN9KLaL0BSjTA1xkYm43htizEfmXogcAqMBh03vlixZpJXCVOK22hj4kW8Tq4MxQDiN1NyWa5s0Qe7c5QGW6zkMrJEL6Swuo0q8blQ1FHpWvyYbH8nYE4j8GrpGJuG4qsQqtbPCMJytJlhAuh1yd0hqYDEVER/Gqri5yQ1nIO73zr7Sh4EDlzndRuFbcqPAneevN1Xal8sX4/Vu+mLYJL2Zq2ELBcVgv/CT/n3bXKNpigxmGIW3OPWgNEvSzErGtpNlYuhMpcPlK2h4LHe5SYiGMLgctiOES2CQzyfxhSPL85CkhQEQTQ3w/mEMKJQIPrGhQRJcwYFPdfI3azF+pfTUnwAhT5z/Bhl9ed3CBkZMwgfp4huEw7ICig4t/UeDqOB6SKURgTsBu4Su5cYhQpzycrWTrs75KhgB 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: 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; /* 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); /*