pr_debug("%s(): memory range at pfn 0x%lx %p is busy, retrying\n",
- __func__, pfn, pfn_to_page(pfn));
+ __func__, pfn, page);
trace_cma_alloc_busy_retry(cma->name, pfn, pfn_to_page(pfn),
Nitpick: I think you already have the page here.
Indeed, forgot to clean that up as well.
count, align);
- /* try again with a bit different memory target */
- start = bitmap_no + mask + 1;
}
out:
- *pagep = page;
+ if (!ret)
+ *pagep = page;
return ret;
}
@@ -882,7 +892,7 @@ static struct page *__cma_alloc(struct cma *cma, unsigned long count,
*/
if (page) {
for (i = 0; i < count; i++)
- page_kasan_tag_reset(nth_page(page, i));
+ page_kasan_tag_reset(page + i);
Had a look at it, not very familiar with CMA, but the changes look equivalent to
what was before. Not sure that's worth a Reviewed-by tag, but here it in case
you want to add it:
Reviewed-by: Alexandru Elisei <alexandru.eli...@arm.com>
Thanks!
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.
So we rule out that case.
--
Cheers
David / dhildenb
