Re: [PATCH v2 3/4] mm/char-mem: implement huge_fault support for /dev/mem

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm/char-mem: unchecked runtime PUD support in
  mmap_mem_huge_fault()
--

commit 231caef4edac4da87c99aec56a1e3e64b13e76e2
Author: Eliav Farber <farbere@amazon.com>

mm/char-mem: implement huge_fault support for /dev/mem

This commit populates non-COW /dev/mem mappings on fault via ->fault and
->huge_fault handlers using vmf_insert_pfn_order() rather than mapping the
entire range eagerly with 4K PTEs at mmap() time.

> diff --git a/mm/char-mem.c b/mm/char-mem.c
> index c5761ddedbd7d..99f02d6a8b07d 100644
> --- a/mm/char-mem.c
> +++ b/mm/char-mem.c
> @@ -318,9 +318,95 @@ static inline int private_mapping_ok(struct vm_area_desc *desc)
>  }
>  #endif
>  
> +#ifdef CONFIG_MMU
> +/*
> + * Populate /dev/mem mappings on fault, using a PMD or PUD mapping where the
> + * architecture, the fault address and the pfn allow it.
> + */
> +static vm_fault_t mmap_mem_huge_fault(struct vm_fault *vmf, unsigned int order)
> +{
> +	unsigned long addr = vmf->address & ~((PAGE_SIZE << order) - 1);
> +	struct vm_area_struct *vma = vmf->vma;
> +	unsigned long pfn;
> +
> +	/*
> +	 * vm_pgoff is the base pfn of the mapping. vmf_pfn_order_ok() ignores
> +	 * pfn if the window starts below vm_start.
> +	 */
> +	pfn = vma->vm_pgoff + ((addr - vma->vm_start) >> PAGE_SHIFT);
> +	if (!vmf_pfn_order_ok(vmf, pfn, order))
> +		return VM_FAULT_FALLBACK;
> +
> +	/*
> +	 * Access was checked at mmap() time, but with CONFIG_IO_STRICT_DEVMEM
> +	 * revoke_iomem() zaps the mapping once a driver claims part of the
> +	 * range. Re-check here so a revoked page is not faulted back in. Like
> +	 * the mmap()-time check, it is not serialised against revoke_iomem(),
> +	 * so a fault that passed it can still install a page revoked right
> +	 * after.
> +	 */
> +	if (!range_is_allowed(pfn, PAGE_SIZE << order))
> +		return order ? VM_FAULT_FALLBACK : VM_FAULT_SIGBUS;
> +
> +	return vmf_insert_pfn_order(vmf, pfn, order);
> +}

[Severity: Medium]
Can mmap_mem_huge_fault() attempt to install a PUD mapping when the
hardware or MMU mode does not support PUD hugepages at runtime?

For VM_PFNMAP mappings, __thp_vma_allowable_orders() allows PUD_ORDER
whenever PMD THP is enabled, and vmf_insert_pfn_order() only checks the
compile-time CONFIG_ARCH_SUPPORTS_PUD_PFNMAP before calling
vmf_insert_pfn_pud():

mm/memory.c:vmf_insert_pfn_order() {
    ...
	if (IS_ENABLED(CONFIG_ARCH_SUPPORTS_PUD_PFNMAP) && order == PUD_ORDER)
		return vmf_insert_pfn_pud(vmf, pfn, write);
    ...
}

Previously /dev/mem only created 4K PTE mappings via remap_pfn_range(),
making this a regression when faulting on a PUD-aligned /dev/mem range.
On PowerPC Book3S 64 running with the Hash MMU (!radix_enabled()),
vmf_insert_pfn_pud() -> insert_pud() -> pfn_pud() -> __pud_mkhuge() hits
an unconditional BUG() under the PUD lock.  On x86_64 systems without
X86_FEATURE_GBPAGES, pud_mkhuge() sets _PAGE_PSE in the PUD entry,
causing a reserved-bit page fault and a kernel oops in pgtable_bad() on
the retried access.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112125638.12209-1-farbere@amazon.com?part=3