Hi David, On Tue, Aug 26, 2025 at 03:08:08PM +0200, David Hildenbrand wrote: > On 26.08.25 15:03, Alexandru Elisei wrote: > > Hi David, > > > > On Tue, Aug 26, 2025 at 01:04:33PM +0200, David Hildenbrand wrote: > > .. > > > > Just so I can better understand the problem being fixed, I guess you > > > > can have > > > > two consecutive pfns with non-consecutive associated struct page if you > > > > have two > > > > adjacent memory sections spanning the same physical memory region, is > > > > that > > > > correct? > > > > > > Exactly. Essentially on SPARSEMEM without SPARSEMEM_VMEMMAP it is not > > > guaranteed that > > > > > > pfn_to_page(pfn + 1) == pfn_to_page(pfn) + 1 > > > > > > when we cross memory section boundaries. > > > > > > It can be the case for early boot memory if we allocated consecutive areas > > > from memblock when allocating the memmap (struct pages) per memory > > > section, > > > but it's not guaranteed. > > > > Thank you for the explanation, but I'm a bit confused by the last > > paragraph. I > > think what you're saying is that we can also have the reverse problem, where > > consecutive struct page * represent non-consecutive pfns, because memmap > > allocations happened to return consecutive virtual addresses, is that right? > > Exactly, that's something we have to deal with elsewhere [1]. For this code, > it's not a problem because we always allocate a contiguous PFN range. > > > > > If that's correct, I don't think that's the case for CMA, which deals out > > contiguous physical memory. Or were you just trying to explain the other > > side of > > the problem, and I'm just overthinking it? > > The latter :)
Ok, sorry for the noise then, and thank you for educating me. Alex
