On Fri, 11 Jul 2025, David Hildenbrand wrote: > On 08.07.25 04:52, Hugh Dickins wrote: > > > > Of course it's limited in what it can catch (and won't even get called > > if the present bit was not set - a more complete patch might unify with > > those various "Bad swap" messages). Of course. But it's still useful for > > stopping pfn_to_page() veering off the end of the memmap[] (in some > > configs). > > Right, probably in the configs we both don't care that much about nowadays :)
I thought it was the other way round: it's useful for stopping pfn_to_page() veering off the end of the memmap[] if it's a memory model where pfn_to_page() is a simple linear conversion. As with SPARSEMEM_VMEMMAP, which I thought was the favourite nowadays. If you don't care about that one much (does hotplug prevent it?), then you do care about the complex pfn_to_page()s, and we should have worried more when "page++"s got unnecessarily converted to folio_page(folio, i) a year or two back (I'm thinking of in mm/rmap.c, maybe elsewhere). Hugh
