On Tue, 1 Sep 2026 21:56:58 +0200 Kiara Grouwstra <[email protected]> wrote:
> dax_associate_entry(), dax_disassociate_entry() and dax_busy_page() each > compute dax_to_folio(entry) in the declaration, one statement before the > test that returns early when the entry is a zero entry or an empty entry. > An empty entry holds no pfn, so dax_to_folio() reads vmemmap[0]. > > Where the memory map starts at pfn 0 this reads a struct page that exists, > the value is discarded, and nothing shows. Where the lowest present section > is above pfn 0 there is no struct page for pfn 0 and the read faults. > grab_mapping_entry() gives the first fault on a file an empty entry, so on > such a machine every first DAX fault on a file ends in: > > BUG: unable to handle page fault for address: ffffea0000000008 > RIP: 0010:dax_to_folio+0x14/0x60 > dax_insert_entry+0xb2/0x3c0 > dax_fault_iter+0x200/0x600 > dax_iomap_pte_fault+0x193/0x3d0 > > Found on a kernel that boots on one high region of system RAM, which has > no struct page for the memory below it. > > Move each call after the early return. The other callers of dax_to_folio() > in this file already only run for an entry that holds a pfn. > Thanks. This is near-identical to https://lore.kernel.org/all/[email protected]/, which I have queued for 7.3-rcX, with cc:stable. Seunguk's fix was set a month ago, but balls were dropped :(
