From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF86A31ED81 for ; Wed, 15 Apr 2026 03:51:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776225065; cv=none; b=K/LGAX0jdTHskiWOgblfV72WyQwjNWyRVOI941U/Z3hrrf2UNYKl3duCqsu66cCD+ym6wrVe/W9oSrEnKQBwcSGQdXDoVjFRmHN0YDnGwjbqhQtZCKWh+8HFg7u7Ni0NmSlPeJ+rPz8jvGLa6/FTZncm3z+npx6h3KU1cEr4F4Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776225065; c=relaxed/simple; bh=0cFJwIzTN6BilLCiuYanjUkVr0OvPKmwc4HVWjdSZVU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=X5CPqwN/qg+Fu8uCoTmVGwbyL4bj1hs4FgQHVUCqzRqjZbnp8pq91Ybi0f9eAsArwE7qZYC0I2knyjXRk9oo8UZpXG5tR5TT8NCGldZquAt5z6zdYF5k3a/hjAF69DtKb6h63KCHHBDgr8bjjleHGIiGrLlelJJv0S42jDrdhXM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JqwJBRPj; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JqwJBRPj" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-82f344e880bso2014080b3a.3 for ; Tue, 14 Apr 2026 20:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776225060; x=1776829860; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CSbdQ1faQzUZHOG/0/OYOqVYaiEfE0LTSulo7jZNh24=; b=JqwJBRPjErj+NouUT8DCK54fZQrpkgcbG7z8bdxSXSxoHx17Grs+gbOfh2Tl0NIYRK o82BnSz/8RpT2y3MJ7Ozc+naS5n3R702S0EmVgAzI5vEpbR/leyo4D70V+s2JVMKN2rJ 8Tj5JfhqSd6hnm6k2PtKALVc6cJQKuJZQikMYa0JiQtPWEHiF5JO9GCcjy6gLrMuovBy 0YTelv5rXoh8u3u0vUrV5i1FNH1rmGP02gXydHqc/7Rd6u3bFpsYNpfAfRCpycQtTsEc mIXg2wMC5+SJ/sFmpn1s/msRmQlSgfN5OlZyqyrK077VuxIgB3FQ/RX98m6YAtVCHPbI KnZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776225060; x=1776829860; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CSbdQ1faQzUZHOG/0/OYOqVYaiEfE0LTSulo7jZNh24=; b=p6dvy03EmHtZwG+/b0Ztz8fVNAXDNrai18Fuj0Dg/ovbTTPInjOMWyVN2VW351i3yg bjiCm3ynwpRpBFA0kFEe+YuoBUNuW8uC+0DvN6WOSQ/4Vnl22ovTZ5N1n/CxLHq/A+4j AqJZgQu19CYdwGb/U2nVsDvjv1cwiv781nZEvqoFhz56bsJZ4DNBKNMzVXxN0NaqWIg9 UqVkOOQhKSqm6xdkCkxgECdwH1Wl9Rymev7nxu0CxAlwZdivi6zDiLLLhvgIREBvsKIP uR/t9Zo75XsvKls6os8nA8ZlqyiUqVBRUiJkjepJcjmrBBMTlX2apwQ+BwYpGyinZ60G kO8g== X-Forwarded-Encrypted: i=1; AFNElJ+SI/wYBNurNfsrUMPLgVQXeFZwkAQSBpChl10I/r7O8HZ9XN1ejFCzAhBo/WpeCePRgA9XNEfH3e7Vyb4=@vger.kernel.org X-Gm-Message-State: AOJu0YzbU9Jf3nZuThjfCqWiHmYSVjE67i1pQ1DpOWKKOk/k14SJ52po nD3gwqiZRHYIWlor6hjmPE71MNKKy0pq82CdxQAt+qw7eE+ql5VSOqrk X-Gm-Gg: AeBDieu2d2UexmRHpWVZ8LReoPMSAzTrdyoWSnImNoqu5L+h2Vxnxz50Fo5sRnkvBgh HpPytG98frg9IxVKADZd8qWLLaAF07ZhgovM9+kQOxmeYa8TkMsP/FSPnbqOaokJEHZpJG141QX ucbo++1okmTYtOyNoyvLnqxr5LB5ECF36CgxeD8PVly16bpKT7LPXomBvRBi/BbhauTCZ5pmnfa MhlYNbQD4HFUMs8YTtF6mpac8GmmCFW4u/9gX/AfatScGi/9UOTkeI04S+EPj5Ne9HDUERkm7Fa x2rmsm1CFYLR1ZjNuLTX7ABYVUiBOMNiiGxIOrJUr9TkbKziYp1HneUJhGSTWQIIORqMcG6hgbz Z/vEpPtO6TTkyRFuAOoKw/3GZ29EZ/o/FvTeoHf5ZfEMoMmaIiHIypn34WuByYpcNNtKDzMSZnr PqCx2/ZaoL18qp93vdFltcmWhS3c09hwwQ0VfQlaInETpg/2c1DZ0I+E+TOzc6g07g9/C0dLIS6 onf8gv4ERvc+9zuGF0S9uPA5Q== X-Received: by 2002:a05:6a00:a217:b0:82c:d7c9:5479 with SMTP id d2e1a72fcca58-82f0c29fe3bmr21203188b3a.32.1776225060222; Tue, 14 Apr 2026 20:51:00 -0700 (PDT) Received: from [127.0.0.1] (211-76-176-102.dynamic-ip.pni.tw. [211.76.176.102]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82f67449c3asm544036b3a.53.2026.04.14.20.50.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2026 20:50:59 -0700 (PDT) Message-ID: Date: Wed, 15 Apr 2026 11:50:50 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 13/13] mm/huge_memory: add and use has_deposited_pgtable() To: "David Hildenbrand (Arm)" , Lorenzo Stoakes Cc: Andrew Morton , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kiryl Shutsemau , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <41b1ff54-c120-42ae-8b74-54767abf3554@gmail.com> <2f29f66b-46db-4925-b922-4add61b633bf@gmail.com> <53d748d3-4150-4e7b-8c1f-4c58587e9183@kernel.org> <6125defb-3aa4-494c-abed-982be684f839@gmail.com> <6417587a-7e43-4615-9e2c-50a245842f59@kernel.org> Content-Language: en-US From: Yin Tirui In-Reply-To: <6417587a-7e43-4615-9e2c-50a245842f59@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi David, On 4/15/26 02:15, David Hildenbrand (Arm) wrote: > On 4/14/26 17:14, Yin Tirui wrote: >> On 4/14/26 17:44, David Hildenbrand (Arm) wrote: >>> >>> I mean, we need some indication to know also during folio splitting >>> whether we can just discard the PMD, as we can refault it later, or >>> whether we really have to install a PTE table. >>> >>> What if someone used remap_pfn_range() on some part of the VMA, and >>> faults on another part? >>> >>> Doesn't really work. >>> >>> Do we have users of remap_pfn_range() that have ->fault set? If not, we >>> should probably just disallow this combination. >> >> I did a quick tree-wide grep: >> $ git grep -l "remap_pfn_range" | xargs grep -l "\.fault\s*=" >> arch/powerpc/platforms/book3s/vas-api.c >> drivers/infiniband/hw/hfi1/file_ops.c >> drivers/uio/uio.c >> drivers/vfio/pci/vfio_pci_core.c >> fs/proc/vmcore.c >> security/selinux/selinuxfs.c >> >> It turns out there are two users of this "hybrid" approach in the kernel: >> 1. fs/proc/vmcore.c: It pre-maps via remap_pfn_range() but registers >> mmap_vmcore_fault(). >> 2. arch/powerpc/platforms/book3s/vas-api.c: It pre-maps via >> remap_pfn_range(), but registers vas_mmap_fault(). >> >>> >>> Then we know for sure whether something was installed through >>> remap_pfn_range() or through a fault handler. >>> >> >> How would you suggest we proceed here? > > How about we populate PMDs in remap_pfn_range() only if !fault? Doing this would at most prevent VMAs with a ->fault() handler from getting huge mappings, which seems to have little negative impact. But wait, dynamic huge mappings are actually created through ->huge_fault(). I did a quick grep: $ git grep -l "remap_pfn_range" | xargs grep -l "\.huge_fault\s*=" drivers/vfio/pci/vfio_pci_core.c This is a false positive. There is no case in the kernel that mixes remap_pfn_range() and ->huge_fault() on the same VMA. What if we use !huge_fault instead, disallowing remap_pfn_range() from populating PMDs if ->huge_fault() is provided? Then, when we encounter a huge PMD, we know for sure whether it was installed through remap_pfn_range() (needs a deposited pgtable) or ->huge_fault() (no deposit needed, can be refaulted). > > Then, if we have !fault, we know that the PMD is from remap_pfn_range() > and has a disposed page table. > > Would that work? > So for Lorenzo's `has_deposited_pgtable()` helper, we could simply use: /* Huge PFN map without a huge_fault handler must deposit */ if (vma_test(vma, VMA_PFNMAP_BIT)) return !vma->vm_ops || !vma->vm_ops->huge_fault; By the way, while auditing this, I noticed that drivers/gpu/drm/drm_gem_shmem_helper.c calls vmf_insert_pfn_pmd() directly from its normal ->fault() handler instead of implementing ->huge_fault(). If we adopt the `!huge_fault` check above, this DRM driver would be wrongly classified as needing a deposit. It seems that DRM driver needs a minor refactoring to properly use ->huge_fault() to keep the MM semantics clean. -- Yin Tirui