From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585861; cv=none; d=zohomail.com; s=zohoarc; b=hVXkoL0/EXybJIC0E6BBdDl7QeDlf88BqLCFxj0qXriP2+5IIGdyOKTz0AKkAAGpoHQoGdQfhQXfTVR68LbYJpQNKo8zrYN7IvDDXJV8ErDhn5UrTcPZfO1t3p8Xu44QmRin2qzwWPy/DozaDbDTyYO5w1pNtY1qgbF5RaSco4s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585861; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=ykT8pgWXFgvGFNKHweTL3CrCV9vUidi0sNJ9Np/Hvr0=; b=mIr0KtFrfnf6nsw6f7IFWq3UQWhHUZ10QiRPvE5rmc3uXn4D3Qm+Ku2conVXZn/wG2QXi3MPd54vdLKdk2mfZY5mqStq/2sQlOuO3zmI2YxKs5s6E1wRa4JKtS7Ho56fIcJt0njzX5tQPCFTY0sfczU5CK1xz1ysur2SoHzL620= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585861797834.9859442559838; Tue, 15 Jul 2025 06:24:21 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044062.1414116 (Exim 4.92) (envelope-from ) id 1ubfda-0004BQ-SM; Tue, 15 Jul 2025 13:24:02 +0000 Received: by outflank-mailman (output) from mailman id 1044062.1414116; Tue, 15 Jul 2025 13:24:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfda-0004BI-Pa; Tue, 15 Jul 2025 13:24:02 +0000 Received: by outflank-mailman (input) for mailman id 1044062; Tue, 15 Jul 2025 13:24:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdZ-0004Ab-DF for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:01 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f6e2d6a9-617e-11f0-a319-13f23c93f187; Tue, 15 Jul 2025 15:23:59 +0200 (CEST) Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-219-rG1iDehYM1Kxca4EnOQEDg-1; Tue, 15 Jul 2025 09:23:56 -0400 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4560f28b2b1so9632015e9.2 for ; Tue, 15 Jul 2025 06:23:56 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3b5e8dc23cfsm15410702f8f.37.2025.07.15.06.23.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:23:53 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f6e2d6a9-617e-11f0-a319-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585838; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ykT8pgWXFgvGFNKHweTL3CrCV9vUidi0sNJ9Np/Hvr0=; b=RL/yB01hT1kOMTVUBoxq4LO/bjAcCZYhgvYpH1Mlub6HHVPyGzlWNU5edlnNmL6HcR9tzq hyIT3S5TgRK+vXNhlc9ISS/96yjuHRIpyEGLM/wQ2NYwWDcRfCrneqhsQs1sjb0POoUJWu n8c8hXMu3MPVq4Dk7gee0Syks2mL3WY= X-MC-Unique: rG1iDehYM1Kxca4EnOQEDg-1 X-Mimecast-MFC-AGG-ID: rG1iDehYM1Kxca4EnOQEDg_1752585835 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585835; x=1753190635; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ykT8pgWXFgvGFNKHweTL3CrCV9vUidi0sNJ9Np/Hvr0=; b=KTrY2s/DB32wjxiT5lrYUrWpylv/JQF0shtZ+ruAX+fGYDJAu3rUwrmBFl7reoAzXR tnd0Im7Ad+MkI+BjOpcxK2RJMcCKAUmJgZ/5J5ThfRWoB8d0lf16EWVk0wfw6kFFR3cq TK64sn3az6omgLQh4hnoupMrGQCBkbQIvVC8iewV6/4s7yblZCz9Pyuhm3ci2NYHQxk4 mCuSIzvYxr0vTsj7NUkW7cjdUKrvOb4Nc+z7jlCkJCiXlPesSBcqX1IROuOX/YimU4Mn r3b4dolqgAyePS+A/c4dbReTNO1cY6wy0hSO0FfgcYbzP4gMT1e+3vO+nqjQsKNZaImJ BV/g== X-Forwarded-Encrypted: i=1; AJvYcCVlJAkyT7WY1s277saDzEx1bdDR2kYxhl24a0s9BHN2WeW5DQ56ywSAJpYQfD4TKiLoRnYMzznuji4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxd7NO7eSs6Dq7wNbvoKyZUBGlnoLavSCkri68kOzuCASAnTnvn wyVwi44ZcYAIbhDfHXXVFQT8cp4/IR8WVJ1eZ89iBsMcItIjF+pYEEIs3KbC0wX9dgytm2Q9due SplGi2cQ9woZjnu2MLturZGnoiULfyq0gKYnaBunA485dAP1EORyam890WwTHFJ7GzZDA X-Gm-Gg: ASbGncsWVm7+SPXYFQ0bisHyR+kDBJWcHdOtcmZjfqiRrmDA3QaEWN8XVufljzvdYLk b4Wevx/b5AFg0ZblGldaV8i81Vmy4Fr/LZZvyyZ4a08kLh8BQnapqozaGoo+pRGWkQP+slOucAF pIftE2aAoN42lsQ/2kQL6TalrMJ+W7pQJ6rXgIs9PJOm3BXFZ+dex05XlpaMF7N9Wt3mz0gZSJA tU0eajjsw/sMFjO3zYloQ5lKXenG+1aBfbuqFgAb6FZtIc6tMtncctM5ak61NsnDhX122PS3gJl 5Z8yo4x93gxIIZpsEAVCnC2Or5pSGPwELCMRCYfPH8Cld/qaaN96x5f01oXmJBJvZDmH72S5HEZ RPUU17061MW6qrvwB8nLW4hmW X-Received: by 2002:a05:6000:144e:b0:3a4:cbc6:9db0 with SMTP id ffacd0b85a97d-3b5f3593547mr14507407f8f.51.1752585835220; Tue, 15 Jul 2025 06:23:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFKDFYln2JrtTRhld2NwLX7CnQQsSirIV2K0GbAl0c8l2mNgbUwK9i9nFjMxSZj5YkY6MStUw== X-Received: by 2002:a05:6000:144e:b0:3a4:cbc6:9db0 with SMTP id ffacd0b85a97d-3b5f3593547mr14507363f8f.51.1752585834604; Tue, 15 Jul 2025 06:23:54 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang , Alistair Popple Subject: [PATCH v1 1/9] mm/huge_memory: move more common code into insert_pmd() Date: Tue, 15 Jul 2025 15:23:42 +0200 Message-ID: <20250715132350.2448901-2-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: V3y3TYXhDsZz-T4jPHxxbjbSjmEr83y4xrUdjhMr6LA_1752585835 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585862360116600 Content-Type: text/plain; charset="utf-8"; x-default="true" Let's clean it all further up. No functional change intended. Reviewed-by: Oscar Salvador Reviewed-by: Alistair Popple Signed-off-by: David Hildenbrand --- mm/huge_memory.c | 72 ++++++++++++++++-------------------------------- 1 file changed, 24 insertions(+), 48 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 31b5c4e61a574..154cafec58dcf 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1390,15 +1390,25 @@ struct folio_or_pfn { bool is_folio; }; =20 -static int insert_pmd(struct vm_area_struct *vma, unsigned long addr, +static vm_fault_t insert_pmd(struct vm_area_struct *vma, unsigned long add= r, pmd_t *pmd, struct folio_or_pfn fop, pgprot_t prot, - bool write, pgtable_t pgtable) + bool write) { struct mm_struct *mm =3D vma->vm_mm; + pgtable_t pgtable =3D NULL; + spinlock_t *ptl; pmd_t entry; =20 - lockdep_assert_held(pmd_lockptr(mm, pmd)); + if (addr < vma->vm_start || addr >=3D vma->vm_end) + return VM_FAULT_SIGBUS; =20 + if (arch_needs_pgtable_deposit()) { + pgtable =3D pte_alloc_one(vma->vm_mm); + if (!pgtable) + return VM_FAULT_OOM; + } + + ptl =3D pmd_lock(mm, pmd); if (!pmd_none(*pmd)) { const unsigned long pfn =3D fop.is_folio ? folio_pfn(fop.folio) : fop.pfn; @@ -1406,15 +1416,14 @@ static int insert_pmd(struct vm_area_struct *vma, u= nsigned long addr, if (write) { if (pmd_pfn(*pmd) !=3D pfn) { WARN_ON_ONCE(!is_huge_zero_pmd(*pmd)); - return -EEXIST; + goto out_unlock; } entry =3D pmd_mkyoung(*pmd); entry =3D maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); if (pmdp_set_access_flags(vma, addr, pmd, entry, 1)) update_mmu_cache_pmd(vma, addr, pmd); } - - return -EEXIST; + goto out_unlock; } =20 if (fop.is_folio) { @@ -1435,11 +1444,17 @@ static int insert_pmd(struct vm_area_struct *vma, u= nsigned long addr, if (pgtable) { pgtable_trans_huge_deposit(mm, pmd, pgtable); mm_inc_nr_ptes(mm); + pgtable =3D NULL; } =20 set_pmd_at(mm, addr, pmd, entry); update_mmu_cache_pmd(vma, addr, pmd); - return 0; + +out_unlock: + spin_unlock(ptl); + if (pgtable) + pte_free(mm, pgtable); + return VM_FAULT_NOPAGE; } =20 /** @@ -1461,9 +1476,6 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, u= nsigned long pfn, struct folio_or_pfn fop =3D { .pfn =3D pfn, }; - pgtable_t pgtable =3D NULL; - spinlock_t *ptl; - int error; =20 /* * If we had pmd_special, we could avoid all these restrictions, @@ -1475,25 +1487,9 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, = unsigned long pfn, (VM_PFNMAP|VM_MIXEDMAP)); BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); =20 - if (addr < vma->vm_start || addr >=3D vma->vm_end) - return VM_FAULT_SIGBUS; - - if (arch_needs_pgtable_deposit()) { - pgtable =3D pte_alloc_one(vma->vm_mm); - if (!pgtable) - return VM_FAULT_OOM; - } - pfnmap_setup_cachemode_pfn(pfn, &pgprot); =20 - ptl =3D pmd_lock(vma->vm_mm, vmf->pmd); - error =3D insert_pmd(vma, addr, vmf->pmd, fop, pgprot, write, - pgtable); - spin_unlock(ptl); - if (error && pgtable) - pte_free(vma->vm_mm, pgtable); - - return VM_FAULT_NOPAGE; + return insert_pmd(vma, addr, vmf->pmd, fop, pgprot, write); } EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd); =20 @@ -1502,35 +1498,15 @@ vm_fault_t vmf_insert_folio_pmd(struct vm_fault *vm= f, struct folio *folio, { struct vm_area_struct *vma =3D vmf->vma; unsigned long addr =3D vmf->address & PMD_MASK; - struct mm_struct *mm =3D vma->vm_mm; struct folio_or_pfn fop =3D { .folio =3D folio, .is_folio =3D true, }; - spinlock_t *ptl; - pgtable_t pgtable =3D NULL; - int error; - - if (addr < vma->vm_start || addr >=3D vma->vm_end) - return VM_FAULT_SIGBUS; =20 if (WARN_ON_ONCE(folio_order(folio) !=3D PMD_ORDER)) return VM_FAULT_SIGBUS; =20 - if (arch_needs_pgtable_deposit()) { - pgtable =3D pte_alloc_one(vma->vm_mm); - if (!pgtable) - return VM_FAULT_OOM; - } - - ptl =3D pmd_lock(mm, vmf->pmd); - error =3D insert_pmd(vma, addr, vmf->pmd, fop, vma->vm_page_prot, - write, pgtable); - spin_unlock(ptl); - if (error && pgtable) - pte_free(mm, pgtable); - - return VM_FAULT_NOPAGE; + return insert_pmd(vma, addr, vmf->pmd, fop, vma->vm_page_prot, write); } EXPORT_SYMBOL_GPL(vmf_insert_folio_pmd); =20 --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585857; cv=none; d=zohomail.com; s=zohoarc; b=jJgBHFJNeVivgA3BoGcWuz1pPE/4pN8u0ITAbu1TYcvs9LSoTivK4euF6wuOAOjIsaRpoYTpnuK01Cih0iBVuLbZJ8zkr3doGodZICxNtYT48rzcJeE+iAvyAwXWyUjBuoa3BXnnHzxE1ZagiX46lqrU/em0/gfgMN3eCnuCaPE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585857; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=oD0dyDm8lg70iaRDQ2YlIByz/7M92Pfar0orAStmNLA=; b=kDGD6M3YjDRJWsQl3z6rxvrI8FB9qCHMKcgLgWL9KUK8jdY1h5ana5WUYo5Iuy4JzReSeurvzOP5ZTtSiX7hxj0MjQsUKJNg3cDaI5Uk+WQ/MAIy6hJR1fsXfb8e0/cyY+qlHH/25Dvt97XBD+q7E3KZKkeZwapG/cMfNKk5pV8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585857659395.17635297632216; Tue, 15 Jul 2025 06:24:17 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044063.1414123 (Exim 4.92) (envelope-from ) id 1ubfdb-0004Ej-6c; Tue, 15 Jul 2025 13:24:03 +0000 Received: by outflank-mailman (output) from mailman id 1044063.1414123; Tue, 15 Jul 2025 13:24:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdb-0004Dq-0O; Tue, 15 Jul 2025 13:24:03 +0000 Received: by outflank-mailman (input) for mailman id 1044063; Tue, 15 Jul 2025 13:24:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfda-0004Ab-1s for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:02 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f7e96911-617e-11f0-a319-13f23c93f187; Tue, 15 Jul 2025 15:24:01 +0200 (CEST) Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-257-CHdjXuz2N_uSpFBN7VHTRw-1; Tue, 15 Jul 2025 09:23:58 -0400 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-3a4edf5bb4dso3979228f8f.0 for ; Tue, 15 Jul 2025 06:23:58 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-454d5037fa0sm200348205e9.7.2025.07.15.06.23.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:23:56 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f7e96911-617e-11f0-a319-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585840; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oD0dyDm8lg70iaRDQ2YlIByz/7M92Pfar0orAStmNLA=; b=Oamsumjz1KdFzKkaF2WqnUxUsk0YDoPBI4pQehS74FCjDYknRhUcgCyKlYBWZgzaYWd/Ft Merq/Wpx5zSJLuNSaLbDINSi8NaHt63YGwV6CeKTIXqAOcXlVUpfs+OeCkOKwXvEQ/LGj7 xI3FNbkA+zBZH2nS+nAmZjrU7eX+lpA= X-MC-Unique: CHdjXuz2N_uSpFBN7VHTRw-1 X-Mimecast-MFC-AGG-ID: CHdjXuz2N_uSpFBN7VHTRw_1752585837 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585837; x=1753190637; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oD0dyDm8lg70iaRDQ2YlIByz/7M92Pfar0orAStmNLA=; b=eKX6/WerMVUnb+AD7nAx9+qUYdRs7L37LiPMZ/BdLdrS+l8aUMQiz3xrqmRUF2JKT3 LmkduB14jbWwPMDeJczklhytZCCmRISI4Fm+kG7W07TxZ/7FUSY7gLW+iqvnAAZdWq2y mtEUVmiM/sNbv0NNEPJeIDfSm/6H5I92z4cTWyOUrgxFLAe7eL47Nm2dVZIhIzzbPUg0 M01wmR/pdROLTzz3ViKZzT4i5RcgBc09QZB0RfSfKZVa5zSZRsRTFMecHDXvry82bRyk nxXeXO5Lg1V9N//FXwI06tWpwQfZs9/YxvHhIc6yEDdUHPhalZ3RhviApxgiZ4LHkvq3 y5mg== X-Forwarded-Encrypted: i=1; AJvYcCX/roEm1yiRwGzYa8UoV1phZGFoPzWyWoue0T2zXk9fHkldYdn4neL0WBrrGeldHi1BzBCHlBMJe5U=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyfx0V70NwmXOf1BY0C7zHOi9xu5eMse8QIrwZsGH0j5ICphbgb DUTz37ygyuVYQI8reQTu183+cy3SRK1lQivI4dKDuWcwgEKR46YyPIqYWRhYM7j8IsD3xiuP1As 9lPFYKA4XMro1uvBQsGK/01FqOdn3N8+XObdu3/8BMLCn/oFZ9jtXO/Bn1s4Sn+MkkyfJ X-Gm-Gg: ASbGnctpT9NzBZrdAN07KVTanLCkWQcw6y56h8CKx2knQS/h7PG8vGCo/kp7UwsvIn7 Nn3ahDMAGsAuE8jQHzKQmt1QzL0esnZp5efwcjqDLfMTqTlDFhXKimqyAwRS1UzSoYXix12nDzN KeXu7YLdGavoREjnq7NXnAYl8Oc/CXHb95HBtcSxS7xPeBZARCu0gzlGxhP/0riLTHNaCLqKyRR cZw3BV5K6E4N1MObmqv7OCu968iOChIWvUPGGAyQ/OtWOsT2Tor3IF1y/GGaX64Pmiccg52FitG YzetD26oWlKpstxaBddmOnwf8UgJkqEoTreFbmVRdNJ0FnIp0TSuHN3dVeQuAHzDrLHP3up0fSc aUXDzIG5FErfB/zracs7WmJWL X-Received: by 2002:a5d:6f1c:0:b0:3a5:527b:64c6 with SMTP id ffacd0b85a97d-3b60a144d0emr2333533f8f.1.1752585837417; Tue, 15 Jul 2025 06:23:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFp1q78RzrsyhD1CJX8BXKE4JqnpAS3jXZChO9oe8FS+N0ne3lTOJKZGuzSFKSesdJ2HD0wXw== X-Received: by 2002:a5d:6f1c:0:b0:3a5:527b:64c6 with SMTP id ffacd0b85a97d-3b60a144d0emr2333512f8f.1.1752585836975; Tue, 15 Jul 2025 06:23:56 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang , Alistair Popple Subject: [PATCH v1 2/9] mm/huge_memory: move more common code into insert_pud() Date: Tue, 15 Jul 2025 15:23:43 +0200 Message-ID: <20250715132350.2448901-3-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3n9dH7PqnGXKuDhVDfch_J3sH6QV-Mu0By4lx5znesA_1752585837 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585859234116600 Content-Type: text/plain; charset="utf-8"; x-default="true" Let's clean it all further up. No functional change intended. Reviewed-by: Oscar Salvador Reviewed-by: Alistair Popple Signed-off-by: David Hildenbrand --- mm/huge_memory.c | 36 +++++++++++++----------------------- 1 file changed, 13 insertions(+), 23 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 154cafec58dcf..1c4a42413042a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1518,25 +1518,30 @@ static pud_t maybe_pud_mkwrite(pud_t pud, struct vm= _area_struct *vma) return pud; } =20 -static void insert_pud(struct vm_area_struct *vma, unsigned long addr, +static vm_fault_t insert_pud(struct vm_area_struct *vma, unsigned long add= r, pud_t *pud, struct folio_or_pfn fop, pgprot_t prot, bool write) { struct mm_struct *mm =3D vma->vm_mm; + spinlock_t *ptl; pud_t entry; =20 + if (addr < vma->vm_start || addr >=3D vma->vm_end) + return VM_FAULT_SIGBUS; + + ptl =3D pud_lock(mm, pud); if (!pud_none(*pud)) { const unsigned long pfn =3D fop.is_folio ? folio_pfn(fop.folio) : fop.pfn; =20 if (write) { if (WARN_ON_ONCE(pud_pfn(*pud) !=3D pfn)) - return; + goto out_unlock; entry =3D pud_mkyoung(*pud); entry =3D maybe_pud_mkwrite(pud_mkdirty(entry), vma); if (pudp_set_access_flags(vma, addr, pud, entry, 1)) update_mmu_cache_pud(vma, addr, pud); } - return; + goto out_unlock; } =20 if (fop.is_folio) { @@ -1555,6 +1560,9 @@ static void insert_pud(struct vm_area_struct *vma, un= signed long addr, } set_pud_at(mm, addr, pud, entry); update_mmu_cache_pud(vma, addr, pud); +out_unlock: + spin_unlock(ptl); + return VM_FAULT_NOPAGE; } =20 /** @@ -1576,7 +1584,6 @@ vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, u= nsigned long pfn, struct folio_or_pfn fop =3D { .pfn =3D pfn, }; - spinlock_t *ptl; =20 /* * If we had pud_special, we could avoid all these restrictions, @@ -1588,16 +1595,9 @@ vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, = unsigned long pfn, (VM_PFNMAP|VM_MIXEDMAP)); BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); =20 - if (addr < vma->vm_start || addr >=3D vma->vm_end) - return VM_FAULT_SIGBUS; - pfnmap_setup_cachemode_pfn(pfn, &pgprot); =20 - ptl =3D pud_lock(vma->vm_mm, vmf->pud); - insert_pud(vma, addr, vmf->pud, fop, pgprot, write); - spin_unlock(ptl); - - return VM_FAULT_NOPAGE; + return insert_pud(vma, addr, vmf->pud, fop, pgprot, write); } EXPORT_SYMBOL_GPL(vmf_insert_pfn_pud); =20 @@ -1614,25 +1614,15 @@ vm_fault_t vmf_insert_folio_pud(struct vm_fault *vm= f, struct folio *folio, { struct vm_area_struct *vma =3D vmf->vma; unsigned long addr =3D vmf->address & PUD_MASK; - pud_t *pud =3D vmf->pud; - struct mm_struct *mm =3D vma->vm_mm; struct folio_or_pfn fop =3D { .folio =3D folio, .is_folio =3D true, }; - spinlock_t *ptl; - - if (addr < vma->vm_start || addr >=3D vma->vm_end) - return VM_FAULT_SIGBUS; =20 if (WARN_ON_ONCE(folio_order(folio) !=3D PUD_ORDER)) return VM_FAULT_SIGBUS; =20 - ptl =3D pud_lock(mm, pud); - insert_pud(vma, addr, vmf->pud, fop, vma->vm_page_prot, write); - spin_unlock(ptl); - - return VM_FAULT_NOPAGE; + return insert_pud(vma, addr, vmf->pud, fop, vma->vm_page_prot, write); } EXPORT_SYMBOL_GPL(vmf_insert_folio_pud); #endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */ --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585866; cv=none; d=zohomail.com; s=zohoarc; b=HOOi8WJa6aqzE/G6v1yuDxlzvPRWj+ijzPjz/3qguBsN/p26ecHklddZnHZL8ntnYLqtF8sfsN3jacQ+WdbvYjcLc62RFORtuI7EpkdCHeu9P+eGYqN9pPmXCw0kEXYECLxE36ZbrKzCVlGUkjn9uYkSPn/6HLR0VAWLxv/suFo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585866; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=p0W1gu/DbwB3HO+Ik7b3ciKtc0XnhekWlhthG95RGc8=; b=hwGjn+ljy9FVFKArvPwLozUKVzrfQxwalp7DcyFU5XkcqmS9vYXAn1O/JoJW3q7sDKi1zIrGNmVpOX/55c2R17tDL6pnXvnLbzqVfSoDQGVC+3hoHwjwz+4UOhn1zcPI5Hj4rDS2MP4ZeFJwcsjbPb0gVtasK2SMiRPZPws4Ny4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 175258586667043.788001508977004; Tue, 15 Jul 2025 06:24:26 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044064.1414137 (Exim 4.92) (envelope-from ) id 1ubfde-0004gB-Cn; Tue, 15 Jul 2025 13:24:06 +0000 Received: by outflank-mailman (output) from mailman id 1044064.1414137; Tue, 15 Jul 2025 13:24:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfde-0004g1-A1; Tue, 15 Jul 2025 13:24:06 +0000 Received: by outflank-mailman (input) for mailman id 1044064; Tue, 15 Jul 2025 13:24:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdc-0004Ab-QI for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:04 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f9a34e17-617e-11f0-a319-13f23c93f187; Tue, 15 Jul 2025 15:24:04 +0200 (CEST) Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-496-uAMBuaixNmWpABpBWaNzJQ-1; Tue, 15 Jul 2025 09:24:01 -0400 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4561bc2f477so13651245e9.0 for ; Tue, 15 Jul 2025 06:24:01 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-45617f18d99sm69437455e9.8.2025.07.15.06.23.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:23:58 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f9a34e17-617e-11f0-a319-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585842; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p0W1gu/DbwB3HO+Ik7b3ciKtc0XnhekWlhthG95RGc8=; b=ES2DbM6k93F7He+Avf+w57uFeYf9327Rd04uycw+lYlG8X1QjXtz2KUliQqIw32kYIMa2J cg/juIaruktU7VTfLoZ2J5XYAE+ojhrdnpmpog5Uq5FazBuUjTRegU1sXZctVrdZ+15r1S Yn9EXoU/GLagiPOFa+acXjowP6lgX+I= X-MC-Unique: uAMBuaixNmWpABpBWaNzJQ-1 X-Mimecast-MFC-AGG-ID: uAMBuaixNmWpABpBWaNzJQ_1752585840 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585840; x=1753190640; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=p0W1gu/DbwB3HO+Ik7b3ciKtc0XnhekWlhthG95RGc8=; b=gRoxybHWIumj003Du/GfWBDAUpAFB6XkukVp4j/jay+QWUMK2HthKJ2nbprFOXooDg vdq2a2Yboy0xv5vvJR8fXKzHjh9AcekqbfvPlLIGZaIo0CSTwNRXqfTBn1tslpFOTn9z fijCxVewVvdkxEkLi0CD0dVA9X2JA16+Uh22m7yaA7aqIQm1+wWu0dZD/JFOZN8eiB2C Wm34Ty038Fsg96r84CkOLwqT/dB3feuDsEC20zoN2j4kUQZGg7gKVFOpJGtzyPvpmX4I vOrWX4TvMyB1RBxgyxrWopDlm51v9Fd+57edBoIPDrLg1yHFJH0z1wuLRwlm9eq6uhGM XkQg== X-Forwarded-Encrypted: i=1; AJvYcCUcRCT0gCCbrX97pRnqNubCRUTnm4STEFIuv44bhyp2lZkwRLUmKFQVPASt3q7TN/K68BPrrMsd4ak=@lists.xenproject.org X-Gm-Message-State: AOJu0YyJAAjxUDxENv6tTcc5jNN4tIu8d/R8rMIU34ZGifElzUGeDcjl MasOj6BdOPDU92LWPlyk2iLbPteziYOkNi0fWyAp2sCh26qJxSYR+AvwhS7BUc/Kfcuuk+5H1bY P+jSLBjVNF0PJM2dVOak87g9cQA9ksEzrT1QuTgxhbNNGM+RuupDxfPIgrRVgBQQqwWlu X-Gm-Gg: ASbGncueb8Q0VMhFcUTRIJbGCwjy0VN411PJnt+3nSmpEOt1OMY4hjt3lm+OA7wGCmV OP712nCPe+ssD+tGdMfTe+Mdo0adHsHvL7fUI85TCmSVw10wbUAyLMcnBDEGISFWCE1Wb1isIwU wiG2PSEDV8c7vqIVtegAnJVUlt1j/ISNCInmUNKFb5Jv5Nk+VF6f7i3pcgRjle4MtnmGiYtuXzu YFlfJUUMYry7+Xg9WR7rGEPYJg1jF/LkKswPg87+j6Z1TO5tMadzpXh1lQF9e3VkRA+xs9Cu5mc yaSChQJNtPzRwwpyPV5h/jwhPdBulzRcDlLyB2OaBWlFEhb4M1L2Q9UtFdwgEPB/bjJ6/mvVViJ ZD/7mnUfDFYGNK/w/RON2pJ00 X-Received: by 2002:a05:600c:5387:b0:456:76c:84f2 with SMTP id 5b1f17b1804b1-456076c88c8mr137334455e9.30.1752585839958; Tue, 15 Jul 2025 06:23:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGYbWegCM0S6a5gfkNemwi6OlAVodA9645Tyw+PVXIOkDyOGbitNWxrBtqQg62ekGoPNGMvNw== X-Received: by 2002:a05:600c:5387:b0:456:76c:84f2 with SMTP id 5b1f17b1804b1-456076c88c8mr137333805e9.30.1752585839359; Tue, 15 Jul 2025 06:23:59 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang Subject: [PATCH v1 3/9] mm/huge_memory: support huge zero folio in vmf_insert_folio_pmd() Date: Tue, 15 Jul 2025 15:23:44 +0200 Message-ID: <20250715132350.2448901-4-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ru3DkocGovtALxnSvDvFDZFVw7pbvF9xWb7aX6BIlwc_1752585840 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585868394116600 Content-Type: text/plain; charset="utf-8"; x-default="true" Just like we do for vmf_insert_page_mkwrite() -> ... -> insert_page_into_pte_locked() with the shared zeropage, support the huge zero folio in vmf_insert_folio_pmd(). When (un)mapping the huge zero folio in page tables, we neither adjust the refcount nor the mapcount, just like for the shared zeropage. For now, the huge zero folio is not marked as special yet, although vm_normal_page_pmd() really wants to treat it as special. We'll change that next. Reviewed-by: Oscar Salvador Signed-off-by: David Hildenbrand --- mm/huge_memory.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 1c4a42413042a..9ec7f48efde09 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1429,9 +1429,11 @@ static vm_fault_t insert_pmd(struct vm_area_struct *= vma, unsigned long addr, if (fop.is_folio) { entry =3D folio_mk_pmd(fop.folio, vma->vm_page_prot); =20 - folio_get(fop.folio); - folio_add_file_rmap_pmd(fop.folio, &fop.folio->page, vma); - add_mm_counter(mm, mm_counter_file(fop.folio), HPAGE_PMD_NR); + if (!is_huge_zero_folio(fop.folio)) { + folio_get(fop.folio); + folio_add_file_rmap_pmd(fop.folio, &fop.folio->page, vma); + add_mm_counter(mm, mm_counter_file(fop.folio), HPAGE_PMD_NR); + } } else { entry =3D pmd_mkhuge(pfn_pmd(fop.pfn, prot)); entry =3D pmd_mkspecial(entry); --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585864; cv=none; d=zohomail.com; s=zohoarc; b=VKKkFBNPavPYzFXXdESAJAlO4i3gu5d/RlKt3q1zekT68UzvY5gBSqHmM4i+MxbU+zIj7AzhWCHDdReXMX21+FbZXctCpjUAJhS6gHrPxOtq99JflTeeNRlSiGerrAiOxBjoVyDXASwNrNYNnFY573d9FwK5J8B4hti724wgIi0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585864; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=80PJLXORrw3H7rwjCmXyFxVPsu/BFZ5pBpUGrZ/8JVA=; b=NmJmweF9ihrA9hHz5N+kG7+4AheSWSx0MjvxA0Z2417sFpeOnGzhEZnRhnOZLdGZOEFboyOWNT9dhgMLTGiEjt/ljbOIJRAFcciUxyWa1dewOK+VHmp/JHoytmnExilmdpCoTqye3Mv3AFrbNbbIuve32a3A85lQRHuoKtZS5do= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585864403447.8189692190326; Tue, 15 Jul 2025 06:24:24 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044065.1414146 (Exim 4.92) (envelope-from ) id 1ubfdf-0004w5-KR; Tue, 15 Jul 2025 13:24:07 +0000 Received: by outflank-mailman (output) from mailman id 1044065.1414146; Tue, 15 Jul 2025 13:24:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdf-0004vs-H1; Tue, 15 Jul 2025 13:24:07 +0000 Received: by outflank-mailman (input) for mailman id 1044065; Tue, 15 Jul 2025 13:24:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfde-0004Ab-SJ for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:06 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fb00aabd-617e-11f0-a319-13f23c93f187; Tue, 15 Jul 2025 15:24:06 +0200 (CEST) Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-474-HF9NURg9MTaqfOz4V4eo7w-1; Tue, 15 Jul 2025 09:24:03 -0400 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3a4f858bc5eso4181566f8f.0 for ; Tue, 15 Jul 2025 06:24:03 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3b5e8e0d719sm15297274f8f.54.2025.07.15.06.24.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:24:01 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb00aabd-617e-11f0-a319-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585845; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=80PJLXORrw3H7rwjCmXyFxVPsu/BFZ5pBpUGrZ/8JVA=; b=JGqOZEo+oTLb9+6P/0Om5vIyePNysJU41M+u0s5NJxTpa4rTA4HgxgL9JjTniOWyz1yLQI 9MApVInTIQ0r3jU1tZhn3QCL4Vkosdf7RrvBIfsx9kS+2gKGB+4sV3SlnqwMAxr04OpTmu uIHEKUxsCbI7ZpddttgEm+WjAiMltrI= X-MC-Unique: HF9NURg9MTaqfOz4V4eo7w-1 X-Mimecast-MFC-AGG-ID: HF9NURg9MTaqfOz4V4eo7w_1752585843 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585842; x=1753190642; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=80PJLXORrw3H7rwjCmXyFxVPsu/BFZ5pBpUGrZ/8JVA=; b=SOZ8APh8nWDnOFjjX2JU/SM+0jzeR5Ejv6rSPOGyH1R4V/NR8mFoDjcjPcLlIWDI+K ghB9ff7ctXPcwi8+3T9avOXJzl14e1TlJRk4igLpAr8N0GReWCheY2RM6LrK3XMPlVbw mWYNx6xqOcOtqIcz9uo1GFNxvOoTfxJRaLAOBNOlLOd4zPo7uHIQlnD/FDtRL5tEljjn BeMN2xQ72odMt39Q4lgwgCUNR8ptoRxUYfj/CwO0ZLKebgxYukGjkWW08/C15ae2im1L F0Dh/G4WuGmxjIyZ5PIdLWaz/xwpxh6gjNASpBpjbWg3BC/4Ojv5b31VUBX/yZ4kc4/j X7ow== X-Forwarded-Encrypted: i=1; AJvYcCUbilP6jXpPRSs0OFjuP8kHkGU3DqNxeB24GYm08sZ0F9PEzQWmn3qzv/uasQQu8bwBiXXosY6Hzvc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxv4uCcFOC4/e7wvTORx5sAK48m4I9XDUyzTEvWJYJBBMjBZAM4 zvU8W9P3mofzFckm7wxpJ3fjzf5l5Wzg1NxAo3SoTzeQsAcJEQRnlyL01b/RzR1HSs+EA2FuQ85 rQ5TSUuQL8RmHOuARWh0Xo35LQPxyLeoAEMuRZvHuSJsr9jBpQs2RUsUOefTWI9rPqX9p X-Gm-Gg: ASbGncvEbD5hrTYE2tugsjnqgyr8BjEX+yMVcSmvyQOZ0ch+WCDWQ2ti3xOk7cPyMKP 0jpQEKIbSWmLEVaHJGjzztDvXkc2zud95u5IXRgGCAqI1Eqaq05Wpl6tY+QsbBKCSVjm5acyD3Z WxB+/iUxD8vmQwgIVmyB5Xdvj/amXTnHLNqEAWWl2sn+lEhEVFmZymaR+MXxeVSEb5B5I6yr5d4 G0cyj14/YkamsxnfcQl9I3mCVPNsE4GQqsJoa/Pw11jLurI0zQMwerR2X6D9aOpQpL0tJfPM6PB UUwQXz4syFkW9dXlETthDwwYdO/9wqm8LZZSr6zAUeXzHVLpt2hV7soGbAVvEnHm4aFvwQ2gCCT CxFUnHApi4Mve7wRu6kSB4Nmw X-Received: by 2002:a05:6000:230e:b0:3b5:e6f2:9117 with SMTP id ffacd0b85a97d-3b5f2e3083dmr13500633f8f.39.1752585842446; Tue, 15 Jul 2025 06:24:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF4Mv4tTd5MMu5ncCf3BOQ9JFfOJXwaxaOdtEK+d74QRgh71f+xeQhxUGyEq6hfTSErOkM9rA== X-Received: by 2002:a05:6000:230e:b0:3b5:e6f2:9117 with SMTP id ffacd0b85a97d-3b5f2e3083dmr13500595f8f.39.1752585841971; Tue, 15 Jul 2025 06:24:01 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang Subject: [PATCH v1 4/9] fs/dax: use vmf_insert_folio_pmd() to insert the huge zero folio Date: Tue, 15 Jul 2025 15:23:45 +0200 Message-ID: <20250715132350.2448901-5-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: DftVzNdCgd7nbb0kHaUmfFd-FFeH73VGyvHR4J9cDGw_1752585843 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585866479116600 Content-Type: text/plain; charset="utf-8"; x-default="true" Let's convert to vmf_insert_folio_pmd(). There is a theoretical change in behavior: in the unlikely case there is already something mapped, we'll now still call trace_dax_pmd_load_hole() and return VM_FAULT_NOPAGE. Previously, we would have returned VM_FAULT_FALLBACK, and the caller would have zapped the PMD to try a PTE fault. However, that behavior was different to other PTE+PMD faults, when there would already be something mapped, and it's not even clear if it could be triggered. Assuming the huge zero folio is already mapped, all good, no need to fallback to PTEs. Assuming there is already a leaf page table ... the behavior would be just like when trying to insert a PMD mapping a folio through dax_fault_iter()->vmf_insert_folio_pmd(). Assuming there is already something else mapped as PMD? It sounds like a BUG, and the behavior would be just like when trying to insert a PMD mapping a folio through dax_fault_iter()->vmf_insert_folio_pmd(). So, it sounds reasonable to not handle huge zero folios differently to inserting PMDs mapping folios when there already is something mapped. Signed-off-by: David Hildenbrand Reviewed-by: Alistair Popple --- fs/dax.c | 47 ++++++++++------------------------------------- 1 file changed, 10 insertions(+), 37 deletions(-) diff --git a/fs/dax.c b/fs/dax.c index 4229513806bea..ae90706674a3f 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -1375,51 +1375,24 @@ static vm_fault_t dax_pmd_load_hole(struct xa_state= *xas, struct vm_fault *vmf, const struct iomap_iter *iter, void **entry) { struct address_space *mapping =3D vmf->vma->vm_file->f_mapping; - unsigned long pmd_addr =3D vmf->address & PMD_MASK; - struct vm_area_struct *vma =3D vmf->vma; struct inode *inode =3D mapping->host; - pgtable_t pgtable =3D NULL; struct folio *zero_folio; - spinlock_t *ptl; - pmd_t pmd_entry; - unsigned long pfn; + vm_fault_t ret; =20 zero_folio =3D mm_get_huge_zero_folio(vmf->vma->vm_mm); =20 - if (unlikely(!zero_folio)) - goto fallback; - - pfn =3D page_to_pfn(&zero_folio->page); - *entry =3D dax_insert_entry(xas, vmf, iter, *entry, pfn, - DAX_PMD | DAX_ZERO_PAGE); - - if (arch_needs_pgtable_deposit()) { - pgtable =3D pte_alloc_one(vma->vm_mm); - if (!pgtable) - return VM_FAULT_OOM; - } - - ptl =3D pmd_lock(vmf->vma->vm_mm, vmf->pmd); - if (!pmd_none(*(vmf->pmd))) { - spin_unlock(ptl); - goto fallback; + if (unlikely(!zero_folio)) { + trace_dax_pmd_load_hole_fallback(inode, vmf, zero_folio, *entry); + return VM_FAULT_FALLBACK; } =20 - if (pgtable) { - pgtable_trans_huge_deposit(vma->vm_mm, vmf->pmd, pgtable); - mm_inc_nr_ptes(vma->vm_mm); - } - pmd_entry =3D folio_mk_pmd(zero_folio, vmf->vma->vm_page_prot); - set_pmd_at(vmf->vma->vm_mm, pmd_addr, vmf->pmd, pmd_entry); - spin_unlock(ptl); - trace_dax_pmd_load_hole(inode, vmf, zero_folio, *entry); - return VM_FAULT_NOPAGE; + *entry =3D dax_insert_entry(xas, vmf, iter, *entry, folio_pfn(zero_folio), + DAX_PMD | DAX_ZERO_PAGE); =20 -fallback: - if (pgtable) - pte_free(vma->vm_mm, pgtable); - trace_dax_pmd_load_hole_fallback(inode, vmf, zero_folio, *entry); - return VM_FAULT_FALLBACK; + ret =3D vmf_insert_folio_pmd(vmf, zero_folio, false); + if (ret =3D=3D VM_FAULT_NOPAGE) + trace_dax_pmd_load_hole(inode, vmf, zero_folio, *entry); + return ret; } #else static vm_fault_t dax_pmd_load_hole(struct xa_state *xas, struct vm_fault = *vmf, --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585871; cv=none; d=zohomail.com; s=zohoarc; b=h29WCP+gI7WNqlDRZZmXgg4oHGnbH6pxe+1XI2ryfiFrY+5Yrebpyz/oe3A66u3qt6p/l0gVIIQWgl03GHkA/riiWD515Cwopj8sD8RMF2mKlrS3zKmnb9tzSxx9zHk1gbKvNDaAV3/x0ZH4j8ys8JXaVCmEUGZBJX/V6Tr/9kc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585871; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=Qf0T+96rABqxKpEz5mD8vzC45xOAiNOzYXCwXWS86uE=; b=Exue0VaOvNMxxVkzNfde7JOBG5qhDTH49HKrmsUZmpvHtyd1YlMS2wxQSlNhk39xCzbPZmcm11KMaERu/LoPQIO+rEdpGPXg7Yme/ti+5gHq+U4hwjW1pP5N2ttNupRag22m2TdnVCswMuWawfHWjQPsSReouhBVmaHjyo7vDok= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585871091721.2334116868058; Tue, 15 Jul 2025 06:24:31 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044068.1414157 (Exim 4.92) (envelope-from ) id 1ubfdk-0005JM-1V; Tue, 15 Jul 2025 13:24:12 +0000 Received: by outflank-mailman (output) from mailman id 1044068.1414157; Tue, 15 Jul 2025 13:24:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdj-0005JC-UB; Tue, 15 Jul 2025 13:24:11 +0000 Received: by outflank-mailman (input) for mailman id 1044068; Tue, 15 Jul 2025 13:24:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdi-0004Ab-JI for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:10 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fd0d248f-617e-11f0-a319-13f23c93f187; Tue, 15 Jul 2025 15:24:09 +0200 (CEST) Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-58-hNJ-82SGMR6W4QfYSvN2yg-1; Tue, 15 Jul 2025 09:24:06 -0400 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4561dfd07bcso10963395e9.1 for ; Tue, 15 Jul 2025 06:24:06 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-45611a518c2sm80433825e9.31.2025.07.15.06.24.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:24:03 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd0d248f-617e-11f0-a319-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585848; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Qf0T+96rABqxKpEz5mD8vzC45xOAiNOzYXCwXWS86uE=; b=i+bQhlMOMN73cMF+KTVkIwuv5covZlnFPO5u30HB27FrIfHVLIibJ37Ai/pXI6uPbDAn5K 9b7Na2b/BAHKN3i9xdjxoDeN10c9xlgpj7tb4whaGtGLgyBa0weulFpjD6doPAQUp6wqVk tGSspKaygvwoeE6VmpeMdbiF8BhkF/g= X-MC-Unique: hNJ-82SGMR6W4QfYSvN2yg-1 X-Mimecast-MFC-AGG-ID: hNJ-82SGMR6W4QfYSvN2yg_1752585845 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585845; x=1753190645; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Qf0T+96rABqxKpEz5mD8vzC45xOAiNOzYXCwXWS86uE=; b=RVnzhlUJSd0dPnGoWxo1aR3+OiknbSiG0wj5PLFsNu1CH5PjW6df3+i+qCnlRsNyQv NnXja9twknqgPUbCOvHQ9IHnAOJ7r00gZ79ppxxbfVfCvtM7Pr5x72aHg1eZXZpf42vi Hxn3J7J5fVcVj88s3uaeO0uzd2tIo2mvNSWyslwFDXU4CiTSnQt/Jmx47gIjhYB1HqKK OBfMagjSZdwmy0e5Z+OxfGWUx0bUJjFXK6IqUlX40OTWLd3yzXDWyM3E5O8gr5iM5mb7 RHC67hqLsULtAqt8IPzFmsedpbIUSq8mulHVl+vlc6Tt2+GouztI2llgfKy5/+bt+EJw GtqA== X-Forwarded-Encrypted: i=1; AJvYcCUiCNQVPzQWj/yG/gHhOtdy3iIG8iTac4AoTXh9DymzSlkfCA0WoLjB4mcDCXKlenS3XfGvgdsrbtE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzn7McoqDnUJkrJ6M2IQH9ZdhCpoUhLfWC/8U5RbWj70aHT9GB4 Yfffma57LsJygblcjcjjxv2EdpSNJnFDuJ3c0SYkpVry+7aWPU/syOJaC7nK39NJ0niSTP7GSET 6BuMUBzoMQ/+CsdTSsGC3d7xIs5oTq4HmxU2XXrLJrM+0CzKT+adTuO9D51OObUw78f0p X-Gm-Gg: ASbGncvBJDXQztEZJFJonI+5qy8FKw1h0VppMH49XqXkFdT3gvH4WzyNV+Bo1mvQrPP Y3E0faV3SY7N3+ka95jd/dHTjvoeV7fyNh0yhDWeupccu8EkbbTUEVRO8j8EkkuQ5INEN9GYoIU q0gKnMR8LIAuay17fygk97uEm0sspq2+Zi/wy1arAw9JXDpgrdEo+DookgznNF/dheJB5lIKCaj 4sjLrRlBVZlu22+fb54PgMNWPtgppFxFXeZ6t+oE93Zuimb8ws/e+pdojFyWafkEsz45lWwFWM3 C3soiTMdTCHpIivIAInUf2s5Y50ijArHkdR4G2Hh71PxwESkzgFmbuh77gvKNSCdFkSo9kpo8ED q1gAE4RzMq11KHipqNudGn5Ec X-Received: by 2002:a05:600c:1c10:b0:456:1e5a:8879 with SMTP id 5b1f17b1804b1-4561e5a903dmr64875955e9.9.1752585844763; Tue, 15 Jul 2025 06:24:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFNkvm/o7SOv8gvxBFeHAl5ZSVtKwdA8aiblR66hArUogUqCn7BZUev9VVrmUri129a2+K3wA== X-Received: by 2002:a05:600c:1c10:b0:456:1e5a:8879 with SMTP id 5b1f17b1804b1-4561e5a903dmr64875585e9.9.1752585844257; Tue, 15 Jul 2025 06:24:04 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang Subject: [PATCH v1 5/9] mm/huge_memory: mark PMD mappings of the huge zero folio special Date: Tue, 15 Jul 2025 15:23:46 +0200 Message-ID: <20250715132350.2448901-6-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: hHCdm2PAytS-hG7it-0_6UUP1NVE9DYD2a07TBdedF0_1752585845 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585872451116600 Content-Type: text/plain; charset="utf-8"; x-default="true" The huge zero folio is refcounted (+mapcounted -- is that a word?) differently than "normal" folios, similarly (but different) to the ordinary shared zeropage. For this reason, we special-case these pages in vm_normal_page*/vm_normal_folio*, and only allow selected callers to still use them (e.g., GUP can still take a reference on them). vm_normal_page_pmd() already filters out the huge zero folio. However, so far we are not marking it as special like we do with the ordinary shared zeropage. Let's mark it as special, so we can further refactor vm_normal_page_pmd() and vm_normal_page(). While at it, update the doc regarding the shared zero folios. Reviewed-by: Oscar Salvador Signed-off-by: David Hildenbrand --- mm/huge_memory.c | 5 ++++- mm/memory.c | 14 +++++++++----- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 9ec7f48efde09..24aff14d22a1e 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1320,6 +1320,7 @@ static void set_huge_zero_folio(pgtable_t pgtable, st= ruct mm_struct *mm, { pmd_t entry; entry =3D folio_mk_pmd(zero_folio, vma->vm_page_prot); + entry =3D pmd_mkspecial(entry); pgtable_trans_huge_deposit(mm, pmd, pgtable); set_pmd_at(mm, haddr, pmd, entry); mm_inc_nr_ptes(mm); @@ -1429,7 +1430,9 @@ static vm_fault_t insert_pmd(struct vm_area_struct *v= ma, unsigned long addr, if (fop.is_folio) { entry =3D folio_mk_pmd(fop.folio, vma->vm_page_prot); =20 - if (!is_huge_zero_folio(fop.folio)) { + if (is_huge_zero_folio(fop.folio)) { + entry =3D pmd_mkspecial(entry); + } else { folio_get(fop.folio); folio_add_file_rmap_pmd(fop.folio, &fop.folio->page, vma); add_mm_counter(mm, mm_counter_file(fop.folio), HPAGE_PMD_NR); diff --git a/mm/memory.c b/mm/memory.c index 3dd6c57e6511e..a4f62923b961c 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -543,7 +543,13 @@ static void print_bad_pte(struct vm_area_struct *vma, = unsigned long addr, * * "Special" mappings do not wish to be associated with a "struct page" (e= ither * it doesn't exist, or it exists but they don't want to touch it). In this - * case, NULL is returned here. "Normal" mappings do have a struct page. + * case, NULL is returned here. "Normal" mappings do have a struct page and + * are ordinarily refcounted. + * + * Page mappings of the shared zero folios are always considered "special"= , as + * they are not ordinarily refcounted. However, selected page table walkers + * (such as GUP) can still identify these mappings and work with the + * underlying "struct page". * * There are 2 broad cases. Firstly, an architecture may define a pte_spec= ial() * pte bit, in which case this function is trivial. Secondly, an architect= ure @@ -573,9 +579,8 @@ static void print_bad_pte(struct vm_area_struct *vma, u= nsigned long addr, * * VM_MIXEDMAP mappings can likewise contain memory with or without "struct * page" backing, however the difference is that _all_ pages with a struct - * page (that is, those where pfn_valid is true) are refcounted and consid= ered - * normal pages by the VM. The only exception are zeropages, which are - * *never* refcounted. + * page (that is, those where pfn_valid is true, except the shared zero + * folios) are refcounted and considered normal pages by the VM. * * The disadvantage is that pages are refcounted (which can be slower and * simply not an option for some PFNMAP users). The advantage is that we @@ -655,7 +660,6 @@ struct page *vm_normal_page_pmd(struct vm_area_struct *= vma, unsigned long addr, { unsigned long pfn =3D pmd_pfn(pmd); =20 - /* Currently it's only used for huge pfnmaps */ if (unlikely(pmd_special(pmd))) return NULL; =20 --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585871; cv=none; d=zohomail.com; s=zohoarc; b=fTfbpl9d8T47V3Gukw58eVUzX0tRCHMr4nVwnqc9FcSd4S+rntDFx9FBdmQPBXF3KGL6y8NLF0YAKRBDvoiLw5lXZiV7BH/4Kn5+ZyEIwVP4yiOEjDBbT6QdhZ8TnuTS6i3Hsp7S794w1p+076NcyZqTn5KKpnmYDlLaMg2+DJw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585871; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=mtQyovPa5kcBmFcu8HFFL9PcOAuE/hqSO0jegAuRWN8=; b=jFpMIumsHUipW1GU7B7gcyskIABRAM4Cxa27fdSjnf/5UQiXVeDwcwzVhGMpl2rNR0FumG28sAXtvTMdCFJ4H4maER1xAhqrI8lubGmTvsTRgk9R0qbOWs+i5BvfZt4FNBA1F1vSvUtT4gNMSobyuDuj3jBdtq0aFB/RBysfCfg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585871669766.410097865676; Tue, 15 Jul 2025 06:24:31 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044072.1414167 (Exim 4.92) (envelope-from ) id 1ubfdp-0005ki-9S; Tue, 15 Jul 2025 13:24:17 +0000 Received: by outflank-mailman (output) from mailman id 1044072.1414167; Tue, 15 Jul 2025 13:24:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdp-0005kW-5R; Tue, 15 Jul 2025 13:24:17 +0000 Received: by outflank-mailman (input) for mailman id 1044072; Tue, 15 Jul 2025 13:24:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdn-0003wf-Dr for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:15 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ff762ce5-617e-11f0-b894-0df219b8e170; Tue, 15 Jul 2025 15:24:13 +0200 (CEST) Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-690-py5HwgK0MpWXq2jJutUlLA-1; Tue, 15 Jul 2025 09:24:09 -0400 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-451d30992bcso43743805e9.2 for ; Tue, 15 Jul 2025 06:24:08 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3b5e8bd1784sm15006827f8f.5.2025.07.15.06.24.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:24:06 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff762ce5-617e-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585852; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mtQyovPa5kcBmFcu8HFFL9PcOAuE/hqSO0jegAuRWN8=; b=WT1TnbNcgfHjpMQyu0/lWYX7Z66qCT9SIPXr7Q+D5RNa08w92BfgqSyRm+teWz7wWvWVyy Yd1N/7VLnJQ6vJmxjjqQBwWf2ybcY/vW8leDaqcev38nN0Gws+UZZa0IkwYN+y1xUH6gSX QsIAmYIDc6sK5O+GDrKh58mNSlJTBRM= X-MC-Unique: py5HwgK0MpWXq2jJutUlLA-1 X-Mimecast-MFC-AGG-ID: py5HwgK0MpWXq2jJutUlLA_1752585848 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585847; x=1753190647; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mtQyovPa5kcBmFcu8HFFL9PcOAuE/hqSO0jegAuRWN8=; b=GBUmoetCKMKpKfTBmfM2JA1PFfhZZDcb5T1yf3dE65QwGM+dLiKfmZBD2uLvBiAT+K YE2WeBiVVFo8npUBRhNNDSfhHBcHiaFCAfEgEj6bmKcOCqxFbjuwIpV57aMDBicwW3rg lHYbzsymuX2SsAliPyTTXWt3cUInG+mip5FvW22/kj+2fCe1oEUqsIncV+M3rV36Xi9W bMt6p+waes5OpyW4JTohB9m7rmTY1rj0lZhML+Te/symyHmOzem+cahrP4JaDL0PWXCq TAX1QwkyH2o9pQ1+VoGMXVv+33tgoZ0Uv+L88FtXCLV+K9kxD+a4amX2rISmTHRBOXgv wjmg== X-Forwarded-Encrypted: i=1; AJvYcCXfZcx6etMzsyhTPeHm64nIEksGoBiAv20q/s5uN5tP1ryufiijB5HfEWGRYfR0+BCvfy4SdNogFqE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxToVwxBZBZXi6PmDODqkEzQczWDG0+SerASIF+6OTWXfowYBoz oVyaW2mujwp1A0g0q+c3lKjiIXw0YiI47ieVyieWQuIFOLc9/Aflrb/Cvorlp63DNFvubt/61Tb 8MMkx0qRA/vCLUZ3xSIdmwBaP9f9iu0ZAov9D6XAmy888h36SzzBQVGIwXuzoswJtVM0P X-Gm-Gg: ASbGncu6NgaDEaXstQFUDOqAnvHDBYfxTycbK5t6APuDkjlAMrxzK2nprhR0PrS09X6 oaW+Yv7D/n9xwBbg2S+NSz1ubfZb9MSR8rr9AcBB4txBknHvtHPJzPzc7yF/fGlWRLyfG2xBlJk +H/VEL63Cj50akK4rOMVm/rsJ8Cljr8Q620HSWh0dXC65xWoMjjdsMLgqK4Dhjur4Vqzx8eyjYw EiILeOM3jM276wmcjQMna7Taw1LOIqjDWl6b774Fe0X418M0ZDAopFnPKtE3Vt2dObuRp7taQ6s YgTmhsLX329kGrErxKff2y+2C6/h/3hPx7Bq6Fk5xd+zAS2EmbCwHEbFFkiVOCLlH0ThRo72mw3 Rov0c+A2iIsLZwoOBFnDHS84F X-Received: by 2002:a05:600c:a03:b0:43c:fdbe:4398 with SMTP id 5b1f17b1804b1-454ec14d7a9mr155614885e9.6.1752585847410; Tue, 15 Jul 2025 06:24:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHhLxz868pyKkYQ3l5UGek/RKFLaiQYjZa6zO7PGU/KyOxr3dY8d03i0aN/xQxZNdYxrPnkbQ== X-Received: by 2002:a05:600c:a03:b0:43c:fdbe:4398 with SMTP id 5b1f17b1804b1-454ec14d7a9mr155614375e9.6.1752585846779; Tue, 15 Jul 2025 06:24:06 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang Subject: [PATCH v1 6/9] mm/memory: convert print_bad_pte() to print_bad_page_map() Date: Tue, 15 Jul 2025 15:23:47 +0200 Message-ID: <20250715132350.2448901-7-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _Ig40e_ogn45WBtNkp8q3BSJ9oGimfHWx_-WQozH970_1752585848 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585872616116600 Content-Type: text/plain; charset="utf-8"; x-default="true" print_bad_pte() looks like something that should actually be a WARN or similar, but historically it apparently has proven to be useful to detect corruption of page tables even on production systems -- report the issue and keep the system running to make it easier to actually detect what is going wrong (e.g., multiple such messages might shed a light). As we want to unify vm_normal_page_*() handling for PTE/PMD/PUD, we'll have to take care of print_bad_pte() as well. Let's prepare for using print_bad_pte() also for non-PTEs by adjusting the implementation and renaming the function -- we'll rename it to what we actually print: bad (page) mappings. Maybe it should be called "print_bad_table_entry()"? We'll just call it "print_bad_page_map()" because the assumption is that we are dealing with some (previously) present page table entry that got corrupted in weird ways. Whether it is a PTE or something else will usually become obvious from the page table dump or from the dumped stack. If ever required in the future, we could pass the entry level type similar to "enum rmap_level". For now, let's keep it simple. To make the function a bit more readable, factor out the ratelimit check into is_bad_page_map_ratelimited() and place the dumping of page table content into __dump_bad_page_map_pgtable(). We'll now dump information from each level in a single line, and just stop the table walk once we hit something that is not a present page table. Use print_bad_page_map() in vm_normal_page_pmd() similar to how we do it for vm_normal_page(), now that we have a function that can handle it. The report will now look something like (dumping pgd to pmd values): [ 77.943408] BUG: Bad page map in process XXX entry:80000001233f5867 [ 77.944077] addr:00007fd84bb1c000 vm_flags:08100071 anon_vma: ... [ 77.945186] pgd:10a89f067 p4d:10a89f067 pud:10e5a2067 pmd:105327067 Signed-off-by: David Hildenbrand --- mm/memory.c | 120 ++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 94 insertions(+), 26 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index a4f62923b961c..00ee0df020503 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -479,22 +479,8 @@ static inline void add_mm_rss_vec(struct mm_struct *mm= , int *rss) add_mm_counter(mm, i, rss[i]); } =20 -/* - * This function is called to print an error when a bad pte - * is found. For example, we might have a PFN-mapped pte in - * a region that doesn't allow it. - * - * The calling function must still handle the error. - */ -static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr, - pte_t pte, struct page *page) +static bool is_bad_page_map_ratelimited(void) { - pgd_t *pgd =3D pgd_offset(vma->vm_mm, addr); - p4d_t *p4d =3D p4d_offset(pgd, addr); - pud_t *pud =3D pud_offset(p4d, addr); - pmd_t *pmd =3D pmd_offset(pud, addr); - struct address_space *mapping; - pgoff_t index; static unsigned long resume; static unsigned long nr_shown; static unsigned long nr_unshown; @@ -506,7 +492,7 @@ static void print_bad_pte(struct vm_area_struct *vma, u= nsigned long addr, if (nr_shown =3D=3D 60) { if (time_before(jiffies, resume)) { nr_unshown++; - return; + return true; } if (nr_unshown) { pr_alert("BUG: Bad page map: %lu messages suppressed\n", @@ -517,15 +503,87 @@ static void print_bad_pte(struct vm_area_struct *vma,= unsigned long addr, } if (nr_shown++ =3D=3D 0) resume =3D jiffies + 60 * HZ; + return false; +} + +static void __dump_bad_page_map_pgtable(struct mm_struct *mm, unsigned lon= g addr) +{ + unsigned long long pgdv, p4dv, pudv, pmdv; + pgd_t pgd, *pgdp; + p4d_t p4d, *p4dp; + pud_t pud, *pudp; + pmd_t *pmdp; + + /* + * This looks like a fully lockless walk, however, the caller is + * expected to hold the leaf page table lock in addition to other + * rmap/mm/vma locks. So this is just a re-walk to dump page table + * content while any concurrent modifications should be completely + * prevented. + */ + pgdp =3D pgd_offset(mm, addr); + pgd =3D pgdp_get(pgdp); + pgdv =3D pgd_val(pgd); + + if (!pgd_present(pgd) || pgd_leaf(pgd)) { + pr_alert("pgd:%08llx\n", pgdv); + return; + } + + p4dp =3D p4d_offset(pgdp, addr); + p4d =3D p4dp_get(p4dp); + p4dv =3D p4d_val(p4d); + + if (!p4d_present(p4d) || p4d_leaf(p4d)) { + pr_alert("pgd:%08llx p4d:%08llx\n", pgdv, p4dv); + return; + } + + pudp =3D pud_offset(p4dp, addr); + pud =3D pudp_get(pudp); + pudv =3D pud_val(pud); + + if (!pud_present(pud) || pud_leaf(pud)) { + pr_alert("pgd:%08llx p4d:%08llx pud:%08llx\n", pgdv, p4dv, pudv); + return; + } + + pmdp =3D pmd_offset(pudp, addr); + pmdv =3D pmd_val(pmdp_get(pmdp)); + + /* + * Dumping the PTE would be nice, but it's tricky with CONFIG_HIGHPTE, + * because the table should already be mapped by the caller and + * doing another map would be bad. print_bad_page_map() should + * already take care of printing the PTE. + */ + pr_alert("pgd:%08llx p4d:%08llx pud:%08llx pmd:%08llx\n", pgdv, + p4dv, pudv, pmdv); +} + +/* + * This function is called to print an error when a bad page table entry (= e.g., + * corrupted page table entry) is found. For example, we might have a + * PFN-mapped pte in a region that doesn't allow it. + * + * The calling function must still handle the error. + */ +static void print_bad_page_map(struct vm_area_struct *vma, + unsigned long addr, unsigned long long entry, struct page *page) +{ + struct address_space *mapping; + pgoff_t index; + + if (is_bad_page_map_ratelimited()) + return; =20 mapping =3D vma->vm_file ? vma->vm_file->f_mapping : NULL; index =3D linear_page_index(vma, addr); =20 - pr_alert("BUG: Bad page map in process %s pte:%08llx pmd:%08llx\n", - current->comm, - (long long)pte_val(pte), (long long)pmd_val(*pmd)); + pr_alert("BUG: Bad page map in process %s entry:%08llx", current->comm, = entry); + __dump_bad_page_map_pgtable(vma->vm_mm, addr); if (page) - dump_page(page, "bad pte"); + dump_page(page, "bad page map"); pr_alert("addr:%px vm_flags:%08lx anon_vma:%px mapping:%px index:%lx\n", (void *)addr, vma->vm_flags, vma->anon_vma, mapping, index); pr_alert("file:%pD fault:%ps mmap:%ps mmap_prepare: %ps read_folio:%ps\n", @@ -603,7 +661,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma,= unsigned long addr, if (is_zero_pfn(pfn)) return NULL; =20 - print_bad_pte(vma, addr, pte, NULL); + print_bad_page_map(vma, addr, pte_val(pte), NULL); return NULL; } =20 @@ -631,7 +689,7 @@ struct page *vm_normal_page(struct vm_area_struct *vma,= unsigned long addr, =20 check_pfn: if (unlikely(pfn > highest_memmap_pfn)) { - print_bad_pte(vma, addr, pte, NULL); + print_bad_page_map(vma, addr, pte_val(pte), NULL); return NULL; } =20 @@ -660,8 +718,15 @@ struct page *vm_normal_page_pmd(struct vm_area_struct = *vma, unsigned long addr, { unsigned long pfn =3D pmd_pfn(pmd); =20 - if (unlikely(pmd_special(pmd))) + if (unlikely(pmd_special(pmd))) { + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) + return NULL; + if (is_huge_zero_pfn(pfn)) + return NULL; + + print_bad_page_map(vma, addr, pmd_val(pmd), NULL); return NULL; + } =20 if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) { if (vma->vm_flags & VM_MIXEDMAP) { @@ -680,8 +745,10 @@ struct page *vm_normal_page_pmd(struct vm_area_struct = *vma, unsigned long addr, =20 if (is_huge_zero_pfn(pfn)) return NULL; - if (unlikely(pfn > highest_memmap_pfn)) + if (unlikely(pfn > highest_memmap_pfn)) { + print_bad_page_map(vma, addr, pmd_val(pmd), NULL); return NULL; + } =20 /* * NOTE! We still have PageReserved() pages in the page tables. @@ -1515,7 +1582,7 @@ static __always_inline void zap_present_folio_ptes(st= ruct mmu_gather *tlb, folio_remove_rmap_ptes(folio, page, nr, vma); =20 if (unlikely(folio_mapcount(folio) < 0)) - print_bad_pte(vma, addr, ptent, page); + print_bad_page_map(vma, addr, pte_val(ptent), page); } if (unlikely(__tlb_remove_folio_pages(tlb, page, nr, delay_rmap))) { *force_flush =3D true; @@ -4513,7 +4580,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) } else if (is_pte_marker_entry(entry)) { ret =3D handle_pte_marker(vmf); } else { - print_bad_pte(vma, vmf->address, vmf->orig_pte, NULL); + print_bad_page_map(vma, vmf->address, + pte_val(vmf->orig_pte), NULL); ret =3D VM_FAULT_SIGBUS; } goto out; --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585879; cv=none; d=zohomail.com; s=zohoarc; b=GQAyj7mO+x2cKbKUuq5+4K1w3U5If/v5WFmZqULwoD96TmZ3Wshk2osrm82EQBJud8pg1sNF4WqNBlYfuqdgEPiwibTHq4rns7WwiJYVnd+vCFQkjK0/szjW1wSwwrb59/SYRbMbDWPNbhlIZI75vIFkcPaOU8zJ6gcBUXGvgxQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585879; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=cI2lHUCMuK2zQhlnl2y4PjQd6rkotpnK5tiH1r4owRs=; b=aX7OX2Fx2uJrysNp41ooAiXEQlvtJeUOCZKXBriCpWfR+tUGuPH2GLceIIBJO74K+RdCttkhoCi6iTLID8HhGOC4KpmtyzwpG+HTcBfT9z0ktcdfaYgNCVT5uXZRmt3a1ivRKC1HH6U1VjzmDhAE35xmccm1R0kfCCfOfv/8PDM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585879937244.97913743829417; Tue, 15 Jul 2025 06:24:39 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044073.1414177 (Exim 4.92) (envelope-from ) id 1ubfdq-00061m-Ox; Tue, 15 Jul 2025 13:24:18 +0000 Received: by outflank-mailman (output) from mailman id 1044073.1414177; Tue, 15 Jul 2025 13:24:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdq-00060q-Gv; Tue, 15 Jul 2025 13:24:18 +0000 Received: by outflank-mailman (input) for mailman id 1044073; Tue, 15 Jul 2025 13:24:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdo-0003wf-A5 for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:16 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ff96316b-617e-11f0-b894-0df219b8e170; Tue, 15 Jul 2025 15:24:14 +0200 (CEST) Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-156-RWu_D_W2MmaUrqJSiBrlWQ-1; Tue, 15 Jul 2025 09:24:11 -0400 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-455e9e09afeso19701205e9.2 for ; Tue, 15 Jul 2025 06:24:11 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3b5e8e2710bsm15102268f8f.99.2025.07.15.06.24.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:24:08 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff96316b-617e-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585852; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cI2lHUCMuK2zQhlnl2y4PjQd6rkotpnK5tiH1r4owRs=; b=b66qwkLF/RKUaO+K2pYKUXdeLMt24iBRoY90VWUIGFc2g64h75ffkwJt9LmkbYPqmFRyh/ AGJDpfsW+IJFz06yKqotOzQ0sDOALNcMmaMEUv6HYHtey5w9WsgTJnPma7uh/yB5twr27q zWITw34R5dE8nW2GY4nCEfLUX1FhUu8= X-MC-Unique: RWu_D_W2MmaUrqJSiBrlWQ-1 X-Mimecast-MFC-AGG-ID: RWu_D_W2MmaUrqJSiBrlWQ_1752585850 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585850; x=1753190650; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cI2lHUCMuK2zQhlnl2y4PjQd6rkotpnK5tiH1r4owRs=; b=tTZMfzVThKRIzRTfrY6K5hH3HR5Qs2Z0eBBfHKvw7sHYZqsC3H3wQCuHcKOFcLOz8n wxm4heLEU35RgMgiRw5Ycrqw+X/wdnm9S9sjHlihr8HWuMvpKs/4qWt8t+kRnY30I2YN 0Rci34USXP8I+g7sJ/LF+JPGJwKy4BL0zz2rN1ip0rPawRJ0mLG3ho0VWgBllepMezEp U7cW/T40YWSSIxqvM+adp4+elIOucOZKYSqgEgtqSLKsM62mClAAxraGRjC15j2I3SbI BY8Pjv88PqiuUXXP1YaAAdkv91eZzeZTFygjb+RyzuMWswrJMlF8Ta13iL5oF4bYjcZJ 0mIA== X-Forwarded-Encrypted: i=1; AJvYcCUGl45IeM6xYJ81YJwcGRCGw1S0jPaGvtsMkroJg/htclq1KCNOz7AzRdjt0IbVV5h9FsJS0ynmMsE=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywuo5do25p9FQ5os8HagnRubJcRdKvHxcDADm7rDtVzrMyG3HJQ W5zTA1QViec6DSD+AA7Wp9wqovyE666KYxBmvaiiAL9WxPFEoEPpJySruxryHchZMl5Bek1qGUY LJwDAJiXVAqx2Vp9avEQWxQm9iLVYEluSW7MzMtTRrllkHvt+N/ZfCbUo89uOIV5wkXpX X-Gm-Gg: ASbGnctzdfKSnp2AXOSNBBw1iAZJGgaDvDWPW5LviWJSRUHPZla3ocUgh7k36s9v0m1 dJ5FvGMu7Fl3tmZZqp7p8BaWRcvHEOoUgI8De04Le03yc9Q3OekBaReElb1elF8Ax3VJ4SNv+/X fyj4BVhnDNi55ofgk8joMfuRJcANx6EvJRurirMI80lMU8oIELGYKaJ7vS/m0BicYkAL1cQyKbM Xv7K+XBjRwLIMy9BEuRC9LqOIoSSsaf/DRjc+qtvsV4Ee4osafl/VK4aMspkYnjCcWnzwYRbCNp 7zJKMjGyKsDvvt3FnROCrW913tDmRv/gJSoJ9RCckzKO8xdQP4G/AxKCP/T3sE9h0fqp3cGPvxV /dTyGKpK1zMi+iGHzvYBejpKd X-Received: by 2002:a05:600c:3592:b0:456:173c:8a53 with SMTP id 5b1f17b1804b1-456173c8b27mr94728815e9.2.1752585849655; Tue, 15 Jul 2025 06:24:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGkPjEhwUD11Kc7R628CsdkyUBojyPzeegGbQKL/YV/Ocaib7+IW0nyg3EFT/AEMoIuz4CMUw== X-Received: by 2002:a05:600c:3592:b0:456:173c:8a53 with SMTP id 5b1f17b1804b1-456173c8b27mr94728115e9.2.1752585848983; Tue, 15 Jul 2025 06:24:08 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang Subject: [PATCH v1 7/9] mm/memory: factor out common code from vm_normal_page_*() Date: Tue, 15 Jul 2025 15:23:48 +0200 Message-ID: <20250715132350.2448901-8-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 1fDsbjeqqv3298DMyApglyLWIIHEZoXIj0l9AsVzx5k_1752585850 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585880658116600 Content-Type: text/plain; charset="utf-8"; x-default="true" Let's reduce the code duplication and factor out the non-pte/pmd related magic into vm_normal_page_pfn(). To keep it simpler, check the pfn against both zero folios. We could optimize this, but as it's only for the !CONFIG_ARCH_HAS_PTE_SPECIAL case, it's not a compelling micro-optimization. With CONFIG_ARCH_HAS_PTE_SPECIAL we don't have to check anything else, really. It's a good question if we can even hit the !CONFIG_ARCH_HAS_PTE_SPECIAL scenario in the PMD case in practice: but doesn't really matter, as it's now all unified in vm_normal_page_pfn(). Add kerneldoc for all involved functions. No functional change intended. Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador --- mm/memory.c | 183 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 109 insertions(+), 74 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 00ee0df020503..d5f80419989b9 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -596,8 +596,13 @@ static void print_bad_page_map(struct vm_area_struct *= vma, add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE); } =20 -/* - * vm_normal_page -- This function gets the "struct page" associated with = a pte. +/** + * vm_normal_page_pfn() - Get the "struct page" associated with a PFN in a + * non-special page table entry. + * @vma: The VMA mapping the @pfn. + * @addr: The address where the @pfn is mapped. + * @pfn: The PFN. + * @entry: The page table entry value for error reporting purposes. * * "Special" mappings do not wish to be associated with a "struct page" (e= ither * it doesn't exist, or it exists but they don't want to touch it). In this @@ -609,10 +614,10 @@ static void print_bad_page_map(struct vm_area_struct = *vma, * (such as GUP) can still identify these mappings and work with the * underlying "struct page". * - * There are 2 broad cases. Firstly, an architecture may define a pte_spec= ial() - * pte bit, in which case this function is trivial. Secondly, an architect= ure - * may not have a spare pte bit, which requires a more complicated scheme, - * described below. + * There are 2 broad cases. Firstly, an architecture may define a "special" + * page table entry bit (e.g., pte_special()), in which case this function= is + * trivial. Secondly, an architecture may not have a spare page table + * entry bit, which requires a more complicated scheme, described below. * * A raw VM_PFNMAP mapping (ie. one that is not COWed) is always considere= d a * special mapping (even if there are underlying and valid "struct pages"). @@ -645,15 +650,72 @@ static void print_bad_page_map(struct vm_area_struct = *vma, * don't have to follow the strict linearity rule of PFNMAP mappings in * order to support COWable mappings. * + * This function is not expected to be called for obviously special mappin= gs: + * when the page table entry has the "special" bit set. + * + * Return: Returns the "struct page" if this is a "normal" mapping. Returns + * NULL if this is a "special" mapping. + */ +static inline struct page *vm_normal_page_pfn(struct vm_area_struct *vma, + unsigned long addr, unsigned long pfn, unsigned long long entry) +{ + /* + * With CONFIG_ARCH_HAS_PTE_SPECIAL, any special page table mappings + * (incl. shared zero folios) are marked accordingly and are handled + * by the caller. + */ + if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) { + if (unlikely(vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))) { + if (vma->vm_flags & VM_MIXEDMAP) { + /* If it has a "struct page", it's "normal". */ + if (!pfn_valid(pfn)) + return NULL; + } else { + unsigned long off =3D (addr - vma->vm_start) >> PAGE_SHIFT; + + /* Only CoW'ed anon folios are "normal". */ + if (pfn =3D=3D vma->vm_pgoff + off) + return NULL; + if (!is_cow_mapping(vma->vm_flags)) + return NULL; + } + } + + if (is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)) + return NULL; + } + + /* Cheap check for corrupted page table entries. */ + if (pfn > highest_memmap_pfn) { + print_bad_page_map(vma, addr, entry, NULL); + return NULL; + } + /* + * NOTE! We still have PageReserved() pages in the page tables. + * For example, VDSO mappings can cause them to exist. + */ + VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); + return pfn_to_page(pfn); +} + +/** + * vm_normal_page() - Get the "struct page" associated with a PTE + * @vma: The VMA mapping the @pte. + * @addr: The address where the @pte is mapped. + * @pte: The PTE. + * + * Get the "struct page" associated with a PTE. See vm_normal_page_pfn() + * for details. + * + * Return: Returns the "struct page" if this is a "normal" mapping. Returns + * NULL if this is a "special" mapping. */ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, pte_t pte) { unsigned long pfn =3D pte_pfn(pte); =20 - if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) { - if (likely(!pte_special(pte))) - goto check_pfn; + if (unlikely(pte_special(pte))) { if (vma->vm_ops && vma->vm_ops->find_special_page) return vma->vm_ops->find_special_page(vma, addr); if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) @@ -664,44 +726,21 @@ struct page *vm_normal_page(struct vm_area_struct *vm= a, unsigned long addr, print_bad_page_map(vma, addr, pte_val(pte), NULL); return NULL; } - - /* !CONFIG_ARCH_HAS_PTE_SPECIAL case follows: */ - - if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) { - if (vma->vm_flags & VM_MIXEDMAP) { - if (!pfn_valid(pfn)) - return NULL; - if (is_zero_pfn(pfn)) - return NULL; - goto out; - } else { - unsigned long off; - off =3D (addr - vma->vm_start) >> PAGE_SHIFT; - if (pfn =3D=3D vma->vm_pgoff + off) - return NULL; - if (!is_cow_mapping(vma->vm_flags)) - return NULL; - } - } - - if (is_zero_pfn(pfn)) - return NULL; - -check_pfn: - if (unlikely(pfn > highest_memmap_pfn)) { - print_bad_page_map(vma, addr, pte_val(pte), NULL); - return NULL; - } - - /* - * NOTE! We still have PageReserved() pages in the page tables. - * eg. VDSO mappings can cause them to exist. - */ -out: - VM_WARN_ON_ONCE(is_zero_pfn(pfn)); - return pfn_to_page(pfn); + return vm_normal_page_pfn(vma, addr, pfn, pte_val(pte)); } =20 +/** + * vm_normal_folio() - Get the "struct folio" associated with a PTE + * @vma: The VMA mapping the @pte. + * @addr: The address where the @pte is mapped. + * @pte: The PTE. + * + * Get the "struct folio" associated with a PTE. See vm_normal_page_pfn() + * for details. + * + * Return: Returns the "struct folio" if this is a "normal" mapping. Retur= ns + * NULL if this is a "special" mapping. + */ struct folio *vm_normal_folio(struct vm_area_struct *vma, unsigned long ad= dr, pte_t pte) { @@ -713,6 +752,18 @@ struct folio *vm_normal_folio(struct vm_area_struct *v= ma, unsigned long addr, } =20 #ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES +/** + * vm_normal_page_pmd() - Get the "struct page" associated with a PMD + * @vma: The VMA mapping the @pmd. + * @addr: The address where the @pmd is mapped. + * @pmd: The PMD. + * + * Get the "struct page" associated with a PMD. See vm_normal_page_pfn() + * for details. + * + * Return: Returns the "struct page" if this is a "normal" mapping. Returns + * NULL if this is a "special" mapping. + */ struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long = addr, pmd_t pmd) { @@ -727,37 +778,21 @@ struct page *vm_normal_page_pmd(struct vm_area_struct= *vma, unsigned long addr, print_bad_page_map(vma, addr, pmd_val(pmd), NULL); return NULL; } - - if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) { - if (vma->vm_flags & VM_MIXEDMAP) { - if (!pfn_valid(pfn)) - return NULL; - goto out; - } else { - unsigned long off; - off =3D (addr - vma->vm_start) >> PAGE_SHIFT; - if (pfn =3D=3D vma->vm_pgoff + off) - return NULL; - if (!is_cow_mapping(vma->vm_flags)) - return NULL; - } - } - - if (is_huge_zero_pfn(pfn)) - return NULL; - if (unlikely(pfn > highest_memmap_pfn)) { - print_bad_page_map(vma, addr, pmd_val(pmd), NULL); - return NULL; - } - - /* - * NOTE! We still have PageReserved() pages in the page tables. - * eg. VDSO mappings can cause them to exist. - */ -out: - return pfn_to_page(pfn); + return vm_normal_page_pfn(vma, addr, pfn, pmd_val(pmd)); } =20 +/** + * vm_normal_folio_pmd() - Get the "struct folio" associated with a PMD + * @vma: The VMA mapping the @pmd. + * @addr: The address where the @pmd is mapped. + * @pmd: The PMD. + * + * Get the "struct folio" associated with a PMD. See vm_normal_page_pfn() + * for details. + * + * Return: Returns the "struct folio" if this is a "normal" mapping. Retur= ns + * NULL if this is a "special" mapping. + */ struct folio *vm_normal_folio_pmd(struct vm_area_struct *vma, unsigned long addr, pmd_t pmd) { --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585873; cv=none; d=zohomail.com; s=zohoarc; b=I2FyyIXs/X4ZuvPwGFT8steWCL2lG8dZ+2gT8/3b+hNsgMofI05Vk9MOrFLGDiBvqb6pQeTzJ1d8JvAjcQc1vJpS74Pic276lZDWGVVc0HdT/lr6fYX+lHpfB9uD0paccyBPpTA23tJm2sABGKJ6C5zqd5TSvlQOCIZ3MHj02Vo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585873; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=ipu1K94ir7ZDGEwTFYIjfG52vTt/Yk6xgTkmlb9d9g0=; b=MTfYi8q1d0L5kLzZ9Q7Un1Q271rEpJLIHHlpjUmC77uzmc4IDNP25K1zJr1vDbfMINv74SorFxhTibsrtJrT4Xe86PMEzTBJq3tQrCsZUiu6qv1NSck0D+PFnGe3rfgcwvUIhJMl+lKvblH5SCqIIKerNtDSBEkBlUYT3RRFbqY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585873348446.0655632396073; Tue, 15 Jul 2025 06:24:33 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044075.1414182 (Exim 4.92) (envelope-from ) id 1ubfdr-0006Ct-Co; Tue, 15 Jul 2025 13:24:19 +0000 Received: by outflank-mailman (output) from mailman id 1044075.1414182; Tue, 15 Jul 2025 13:24:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdr-0006B1-7x; Tue, 15 Jul 2025 13:24:19 +0000 Received: by outflank-mailman (input) for mailman id 1044075; Tue, 15 Jul 2025 13:24:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdp-0003wf-Cw for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:17 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 00afcd6f-617f-11f0-b894-0df219b8e170; Tue, 15 Jul 2025 15:24:15 +0200 (CEST) Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-121-aURPM_nvNumdoamKKCBiDA-1; Tue, 15 Jul 2025 09:24:13 -0400 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4560b81ff9eso19992355e9.1 for ; Tue, 15 Jul 2025 06:24:12 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-454dd537c6fsm163863975e9.21.2025.07.15.06.24.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:24:10 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 00afcd6f-617f-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585854; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ipu1K94ir7ZDGEwTFYIjfG52vTt/Yk6xgTkmlb9d9g0=; b=EmFMHeivJULGpdt/+xqA4bWYX6oRvmQ+ZqFHJV/ZIz3Jq5kgxIo8gwjYx1/z59t/LBOXtI Jc+Co2sCG2g0vleDIQik+oI60L8iwYH8Xu1FAzRnRL86erbI1ooLy7HHVR0MFgrte/xiDw VS8E28JvBNuIpD8xeuIxPuzVbLyDJ0w= X-MC-Unique: aURPM_nvNumdoamKKCBiDA-1 X-Mimecast-MFC-AGG-ID: aURPM_nvNumdoamKKCBiDA_1752585852 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585852; x=1753190652; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ipu1K94ir7ZDGEwTFYIjfG52vTt/Yk6xgTkmlb9d9g0=; b=VuzqkuM+pfpev9qHMCHyn+Ji9pVVfV/gYW7/6PVMcG8ttBmMJ3GhWoddT4fa1fJop0 7IIcP9RMhmER58qgO4+KJYj3OhrcS/Gka+UUhbTw/3NfoA4QzAWKPsDYVETMg9quQ7yU evwJQKLqyTyZsm5t1ANQotUiPHLsqDmvGNqGxrFzA3qoh86ZxDXbe1GoqiqbIP//E/pG JRH0QMt+67EqF51lTVrJ48sxsYcjMLbiyoozdUS2AHeFj1q4HQcC6QpSdFZUy4K+Un2Z KWdLFrwL0B5IKeUNE6izGigBhoRxGTiHrq5c3xvdoG7lD4/bieEH5QdgGLvCrMvn5QNl rAHQ== X-Forwarded-Encrypted: i=1; AJvYcCWr5RobulMEqFx708vlzG6i63QeGM1J36fI5k/oROcznwGmSKDyBADKZpehjRzpl1pJGn4nKlxzmYY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxra42hRChgiGGiKAT+K19KVDj4v1qfdNozwR2rwJRFumpSWDH4 2rT/mWh7old4mN/OW9aZPxSYvnU/7bSRplL9BWuOafXWWEGlsqgchvK2qtWZ1nbEtEen+4ysQ2t siW2fanOSX3O8Kh0gDYd554JSFg/a+24DS6xi30MonpZvfB3UZmvLny1Zrc6QTcjE3bxs X-Gm-Gg: ASbGnctrmfQIEbiTU5uUGYeqHaRsSBNy6D2zDLWS8bu1Ba887+/C3s2r1rQWPUV8Dcg 4cDUkpQwvqIm64beEUiO85A818o6oI8BlaRUTtwQceu6T7OixgOD0GSsEgDeVABORipxXuni/wz yGAuXu7aTRbW2HCymfHF8L6dPt/9FoWBTdJfQetqQquGjtXeIRQnlU733/yuZV6SAYdlU/+VPrc G2UuZ/4pXa70TALIEnk0EccsGlFZxhTGgZZ7MbPA/OLUqfGIQzSrvTMNObA6AU2Y5WtkRGziROt iyPK7xJxbEvHI0Rt18KmJnTh59cqAgi4b2Nnp3CY4dfG9deBLKQsRqm/OSvELXjv6XX7361VdnG LtIL94ffgF81EDdCKC5kuMsEN X-Received: by 2002:a05:600c:8b21:b0:43d:42b:e186 with SMTP id 5b1f17b1804b1-454f427c7a3mr171862345e9.8.1752585851887; Tue, 15 Jul 2025 06:24:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEaYqvO7Z17qzgP+gQiOIR1ioSQdxI9NA77sZCIReClJxyu/a9rC4GbIDSj1kdPYM9bqwFuHQ== X-Received: by 2002:a05:600c:8b21:b0:43d:42b:e186 with SMTP id 5b1f17b1804b1-454f427c7a3mr171861965e9.8.1752585851440; Tue, 15 Jul 2025 06:24:11 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang Subject: [PATCH v1 8/9] mm: introduce and use vm_normal_page_pud() Date: Tue, 15 Jul 2025 15:23:49 +0200 Message-ID: <20250715132350.2448901-9-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -MCPm5OJX9awxkXO8KCobCn8z6VX-UHO-9M_8xr18PQ_1752585852 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585874405116600 Content-Type: text/plain; charset="utf-8"; x-default="true" Let's introduce vm_normal_page_pud(), which ends up being fairly simple because of our new common helpers and there not being a PUD-sized zero folio. Use vm_normal_page_pud() in folio_walk_start() to resolve a TODO, structuring the code like the other (pmd/pte) cases. Defer introducing vm_normal_folio_pud() until really used. Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador --- include/linux/mm.h | 2 ++ mm/memory.c | 27 +++++++++++++++++++++++++++ mm/pagewalk.c | 20 ++++++++++---------- 3 files changed, 39 insertions(+), 10 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 611f337cc36c9..6877c894fe526 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2347,6 +2347,8 @@ struct folio *vm_normal_folio_pmd(struct vm_area_stru= ct *vma, unsigned long addr, pmd_t pmd); struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long = addr, pmd_t pmd); +struct page *vm_normal_page_pud(struct vm_area_struct *vma, unsigned long = addr, + pud_t pud); =20 void zap_vma_ptes(struct vm_area_struct *vma, unsigned long address, unsigned long size); diff --git a/mm/memory.c b/mm/memory.c index d5f80419989b9..f1834a19a2f1e 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -802,6 +802,33 @@ struct folio *vm_normal_folio_pmd(struct vm_area_struc= t *vma, return page_folio(page); return NULL; } + +/** + * vm_normal_page_pud() - Get the "struct page" associated with a PUD + * @vma: The VMA mapping the @pud. + * @addr: The address where the @pud is mapped. + * @pud: The PUD. + * + * Get the "struct page" associated with a PUD. See vm_normal_page_pfn() + * for details. + * + * Return: Returns the "struct page" if this is a "normal" mapping. Returns + * NULL if this is a "special" mapping. + */ +struct page *vm_normal_page_pud(struct vm_area_struct *vma, + unsigned long addr, pud_t pud) +{ + unsigned long pfn =3D pud_pfn(pud); + + if (unlikely(pud_special(pud))) { + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) + return NULL; + + print_bad_page_map(vma, addr, pud_val(pud), NULL); + return NULL; + } + return vm_normal_page_pfn(vma, addr, pfn, pud_val(pud)); +} #endif =20 /** diff --git a/mm/pagewalk.c b/mm/pagewalk.c index 648038247a8d2..c6753d370ff4e 100644 --- a/mm/pagewalk.c +++ b/mm/pagewalk.c @@ -902,23 +902,23 @@ struct folio *folio_walk_start(struct folio_walk *fw, fw->pudp =3D pudp; fw->pud =3D pud; =20 - /* - * TODO: FW_MIGRATION support for PUD migration entries - * once there are relevant users. - */ - if (!pud_present(pud) || pud_special(pud)) { + if (pud_none(pud)) { spin_unlock(ptl); goto not_found; - } else if (!pud_leaf(pud)) { + } else if (pud_present(pud) && !pud_leaf(pud)) { spin_unlock(ptl); goto pmd_table; + } else if (pud_present(pud)) { + page =3D vm_normal_page_pud(vma, addr, pud); + if (page) + goto found; } /* - * TODO: vm_normal_page_pud() will be handy once we want to - * support PUD mappings in VM_PFNMAP|VM_MIXEDMAP VMAs. + * TODO: FW_MIGRATION support for PUD migration entries + * once there are relevant users. */ - page =3D pud_page(pud); - goto found; + spin_unlock(ptl); + goto not_found; } =20 pmd_table: --=20 2.50.1 From nobody Tue Oct 7 01:53:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1752585884; cv=none; d=zohomail.com; s=zohoarc; b=m/GI57+ZC0gCluIexuJqvQDKdWdL7xAmcMMhXpnnANmV5I3zQIFWfEz5FUYaufjXAVgyRI3w7cmDFEkNI0cbP1Sl//E2gT9BvCX2hDZR4klAFRF1rN3CQgkex6B4NAjjHr013OOBAF/9ostRqAR46nTO40zJbypyucBl789KH54= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1752585884; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=VQduvI7D6V1Y1gj1ZwNsH+sSV4mM47HI53S/a03rEFE=; b=QRSiMt9jGoLtNvQs6l9ClPeMVHctOcVoVjAdsvHAmWyRTmJE3Atew3lky6GQNXO7nzax9yg1j/WBSuLmhXMRqEBFa7/Rfs9xEjW3oR6vVj8DcIft3mZ+bi3Ud5DZVp7u08+j2dkE8qSFVmxsE8YZNQ7d3y5d3TmeTdROFEFVv3M= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1752585884626481.5692101045971; Tue, 15 Jul 2025 06:24:44 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1044079.1414197 (Exim 4.92) (envelope-from ) id 1ubfdu-0006nC-Tv; Tue, 15 Jul 2025 13:24:22 +0000 Received: by outflank-mailman (output) from mailman id 1044079.1414197; Tue, 15 Jul 2025 13:24:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfdu-0006mI-Nd; Tue, 15 Jul 2025 13:24:22 +0000 Received: by outflank-mailman (input) for mailman id 1044079; Tue, 15 Jul 2025 13:24:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ubfds-0004Ab-Mo for xen-devel@lists.xenproject.org; Tue, 15 Jul 2025 13:24:20 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 033d3d7d-617f-11f0-a319-13f23c93f187; Tue, 15 Jul 2025 15:24:20 +0200 (CEST) Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-307-EqncoupRON-gGx7HOZaKkw-1; Tue, 15 Jul 2025 09:24:15 -0400 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4538a2f4212so31549035e9.2 for ; Tue, 15 Jul 2025 06:24:15 -0700 (PDT) Received: from localhost (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-4560c50b7b4sm100033485e9.25.2025.07.15.06.24.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 06:24:13 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 033d3d7d-617f-11f0-a319-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752585859; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VQduvI7D6V1Y1gj1ZwNsH+sSV4mM47HI53S/a03rEFE=; b=chp7g+FePqpUSB5LSZ2hqT7UowdFtaLHuGtIWXdcD0ANVHEO2B1HAkD0In+nKcujhNPT46 sUMJw3neq0R03Q5Lvp3PqjWAqxoJ+NmXMNxJRKgBa8Kli3IqIA7F9k/MsdAbNP572nAcg+ tZt3Gf3jCemPmqydhcAtMJ3H3NfhDzs= X-MC-Unique: EqncoupRON-gGx7HOZaKkw-1 X-Mimecast-MFC-AGG-ID: EqncoupRON-gGx7HOZaKkw_1752585854 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752585854; x=1753190654; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VQduvI7D6V1Y1gj1ZwNsH+sSV4mM47HI53S/a03rEFE=; b=W5KoOFtk/QftSkDpZytPrcGsnRDGqBeFfJdS79gWJrXck7o4WjJjgY4NSx8FyHG74U 26Vq7zg0q+yn3D3JgHJI6W4cSr5Eun0ICrspey9V+Vu/FFW9zX3eDLo+55DXTjDvHTee M3dRg2C1863l7qYFvt2R2JjdHmIKeK17WVBWNlEfCPkTgaNXWjppCASt3Wg+CfJpk7DZ A8dw+C9LeDgC+bRjLS2q6+MOk11k8bX+d1thlj4U6jI4V0S4qDxIAEJpHv8vEfVnSio2 BfVdFkPSgxV7rC1Nk2YXmmkdRN7OfHRoGmwedYpgsI4/1dF2E4yHe2g76/pOfQvA2pop Hleg== X-Forwarded-Encrypted: i=1; AJvYcCX0PcBEOKf486zRmPRkRZmCap4jr4wUKJiPSzOYA3DnoJYXzr0ct11PWX2vZYjyvJlyYl5Ebb/+knQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxYPAho4cIEXhRQVhklM2zEMXva3zT6ECaKtIfwdJckwynTEYt3 TAskOsqVFYBEjF545wKzkj/fCtzzfc728tpK0uZkmmuJojyhemKMR2Kbmt5fVtFYXfnM9R+Ikto LfyFwnkUlKNGilbww5hGk9tNyjKYic30ev48owBjpYRdoNgoi1WI9zDmAvsJhcFZuKUCZ X-Gm-Gg: ASbGncttobr89M5jHvWa2rDXB6iKUihQuUVS3dqxAuvAF3jOSpVb4zdxlt7iSybQsFM ug7VYIXqugtKv76vtL12CNYQuLdizQUVph5/lvjsPJ9IlQU2Jjkf+hWbTxZ0Kdf3gOH2Jd3KKMJ NDKS0SyZR+cRI4MGFIZX2MxyFk8ffw7OL23TE94T95yi5f8y178JFQyt3Fkpx3g76BVBPwySNlX sU36ffDe0+9bBH+Av/lWOapHBzYuNR0hl+klsICh6YgJkRNE8BvH3cbcfIXvlbq5eQc4clLwPJc uKoUOGQFd2SpNfoL90+SKEa1ejRHxQPw8zcXPzal76wR+OmYmbNQPH7k/iPPWyQcEIHkhvRus2A V+2wej5uTkRpWLkV1iekXL+rd X-Received: by 2002:a05:600c:4ed0:b0:456:1a41:f932 with SMTP id 5b1f17b1804b1-4561a41fd79mr64379175e9.22.1752585854243; Tue, 15 Jul 2025 06:24:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE3r8lG85ntU3nBUSpLXqHodEZFoetPf2QpvNAGJr6E2EBer+0dRaC665FuVYarZxx4ibL6Dg== X-Received: by 2002:a05:600c:4ed0:b0:456:1a41:f932 with SMTP id 5b1f17b1804b1-4561a41fd79mr64378845e9.22.1752585853644; Tue, 15 Jul 2025 06:24:13 -0700 (PDT) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, David Hildenbrand , Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang , David Vrabel Subject: [PATCH v1 9/9] mm: rename vm_ops->find_special_page() to vm_ops->find_normal_page() Date: Tue, 15 Jul 2025 15:23:50 +0200 Message-ID: <20250715132350.2448901-10-david@redhat.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250715132350.2448901-1-david@redhat.com> References: <20250715132350.2448901-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: gxQAWhp_il71uRxvVYyRhH-GXiBzGmFNdRYTmKBySdU_1752585854 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1752585886809116600 Content-Type: text/plain; charset="utf-8"; x-default="true" ... and hide it behind a kconfig option. There is really no need for any !xen code to perform this check. The naming is a bit off: we want to find the "normal" page when a PTE was marked "special". So it's really not "finding a special" page. Improve the documentation, and add a comment in the code where XEN ends up performing the pte_mkspecial() through a hypercall. More details can be found in commit 923b2919e2c3 ("xen/gntdev: mark userspace PTEs as special on x86 PV guests"). Cc: David Vrabel Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador --- drivers/xen/Kconfig | 1 + drivers/xen/gntdev.c | 5 +++-- include/linux/mm.h | 18 +++++++++++++----- mm/Kconfig | 2 ++ mm/memory.c | 12 ++++++++++-- tools/testing/vma/vma_internal.h | 18 +++++++++++++----- 6 files changed, 42 insertions(+), 14 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 24f485827e039..f9a35ed266ecf 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -138,6 +138,7 @@ config XEN_GNTDEV depends on XEN default m select MMU_NOTIFIER + select FIND_NORMAL_PAGE help Allows userspace processes to use grants. =20 diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 61faea1f06630..d1bc0dae2cdf9 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -309,6 +309,7 @@ static int find_grant_ptes(pte_t *pte, unsigned long ad= dr, void *data) BUG_ON(pgnr >=3D map->count); pte_maddr =3D arbitrary_virt_to_machine(pte).maddr; =20 + /* Note: this will perform a pte_mkspecial() through the hypercall. */ gnttab_set_map_op(&map->map_ops[pgnr], pte_maddr, flags, map->grants[pgnr].ref, map->grants[pgnr].domid); @@ -516,7 +517,7 @@ static void gntdev_vma_close(struct vm_area_struct *vma) gntdev_put_map(priv, map); } =20 -static struct page *gntdev_vma_find_special_page(struct vm_area_struct *vm= a, +static struct page *gntdev_vma_find_normal_page(struct vm_area_struct *vma, unsigned long addr) { struct gntdev_grant_map *map =3D vma->vm_private_data; @@ -527,7 +528,7 @@ static struct page *gntdev_vma_find_special_page(struct= vm_area_struct *vma, static const struct vm_operations_struct gntdev_vmops =3D { .open =3D gntdev_vma_open, .close =3D gntdev_vma_close, - .find_special_page =3D gntdev_vma_find_special_page, + .find_normal_page =3D gntdev_vma_find_normal_page, }; =20 /* ------------------------------------------------------------------ */ diff --git a/include/linux/mm.h b/include/linux/mm.h index 6877c894fe526..cc3322fce62f4 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -646,13 +646,21 @@ struct vm_operations_struct { struct mempolicy *(*get_policy)(struct vm_area_struct *vma, unsigned long addr, pgoff_t *ilx); #endif +#ifdef CONFIG_FIND_NORMAL_PAGE /* - * Called by vm_normal_page() for special PTEs to find the - * page for @addr. This is useful if the default behavior - * (using pte_page()) would not find the correct page. + * Called by vm_normal_page() for special PTEs in @vma at @addr. This + * allows for returning a "normal" page from vm_normal_page() even + * though the PTE indicates that the "struct page" either does not exist + * or should not be touched: "special". + * + * Do not add new users: this really only works when a "normal" page + * was mapped, but then the PTE got changed to something weird (+ + * marked special) that would not make pte_pfn() identify the originally + * inserted page. */ - struct page *(*find_special_page)(struct vm_area_struct *vma, - unsigned long addr); + struct page *(*find_normal_page)(struct vm_area_struct *vma, + unsigned long addr); +#endif /* CONFIG_FIND_NORMAL_PAGE */ }; =20 #ifdef CONFIG_NUMA_BALANCING diff --git a/mm/Kconfig b/mm/Kconfig index 0287e8d94aea7..82c281b4f6937 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1397,6 +1397,8 @@ config PT_RECLAIM =20 Note: now only empty user PTE page table pages will be reclaimed. =20 +config FIND_NORMAL_PAGE + def_bool n =20 source "mm/damon/Kconfig" =20 diff --git a/mm/memory.c b/mm/memory.c index f1834a19a2f1e..d09f2ff4a866e 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -619,6 +619,12 @@ static void print_bad_page_map(struct vm_area_struct *= vma, * trivial. Secondly, an architecture may not have a spare page table * entry bit, which requires a more complicated scheme, described below. * + * With CONFIG_FIND_NORMAL_PAGE, we might have the "special" bit set on + * page table entries that actually map "normal" pages: however, that page + * cannot be looked up through the PFN stored in the page table entry, but + * instead will be looked up through vm_ops->find_normal_page(). So far, t= his + * only applies to PTEs. + * * A raw VM_PFNMAP mapping (ie. one that is not COWed) is always considere= d a * special mapping (even if there are underlying and valid "struct pages"). * COWed pages of a VM_PFNMAP are always normal. @@ -716,8 +722,10 @@ struct page *vm_normal_page(struct vm_area_struct *vma= , unsigned long addr, unsigned long pfn =3D pte_pfn(pte); =20 if (unlikely(pte_special(pte))) { - if (vma->vm_ops && vma->vm_ops->find_special_page) - return vma->vm_ops->find_special_page(vma, addr); +#ifdef CONFIG_FIND_NORMAL_PAGE + if (vma->vm_ops && vma->vm_ops->find_normal_page) + return vma->vm_ops->find_normal_page(vma, addr); +#endif /* CONFIG_FIND_NORMAL_PAGE */ if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) return NULL; if (is_zero_pfn(pfn)) diff --git a/tools/testing/vma/vma_internal.h b/tools/testing/vma/vma_inter= nal.h index 991022e9e0d3b..9eecfb1dcc13f 100644 --- a/tools/testing/vma/vma_internal.h +++ b/tools/testing/vma/vma_internal.h @@ -465,13 +465,21 @@ struct vm_operations_struct { struct mempolicy *(*get_policy)(struct vm_area_struct *vma, unsigned long addr, pgoff_t *ilx); #endif +#ifdef CONFIG_FIND_NORMAL_PAGE /* - * Called by vm_normal_page() for special PTEs to find the - * page for @addr. This is useful if the default behavior - * (using pte_page()) would not find the correct page. + * Called by vm_normal_page() for special PTEs in @vma at @addr. This + * allows for returning a "normal" page from vm_normal_page() even + * though the PTE indicates that the "struct page" either does not exist + * or should not be touched: "special". + * + * Do not add new users: this really only works when a "normal" page + * was mapped, but then the PTE got changed to something weird (+ + * marked special) that would not make pte_pfn() identify the originally + * inserted page. */ - struct page *(*find_special_page)(struct vm_area_struct *vma, - unsigned long addr); + struct page *(*find_normal_page)(struct vm_area_struct *vma, + unsigned long addr); +#endif /* CONFIG_FIND_NORMAL_PAGE */ }; =20 struct vm_unmapped_area_info { --=20 2.50.1