On 11.07.25 20:49, Hugh Dickins wrote:
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.
Yes, you're right, I had the !SPARSEMEM model in mind, but obviously,
the same applies for the SPARSEMEM_VMEMMAP case as well.
Only the SPARSEMEM && !SPARSEMEM_VMEMMAP model is weird. IIRC, it will
dereference NULL when given a non-existant PFN. (__nr_to_section
returning NULL and pfn_to_section_nr() not beeing happy about that)
--
Cheers,
David / dhildenb
