On 8 Sep 2023, at 10:46, Philippe Mathieu-Daudé wrote: > Hi, > > On 6/9/23 17:03, Zi Yan wrote: >> From: Zi Yan <ziy@xxxxxxxxxx> >> >> On SPARSEMEM without VMEMMAP, struct page is not guaranteed to be >> contiguous, since each memory section's memmap might be allocated >> independently. hugetlb pages can go beyond a memory section size, thus >> direct struct page manipulation on hugetlb pages/subpages might give >> wrong struct page. Kernel provides nth_page() to do the manipulation >> properly. Use that whenever code can see hugetlb pages. > > How can we notice "whenever code can see hugetlb pages"? > From your series it seems you did a manual code audit, is that correct? > (I ask because I'm wondering about code scalability and catching other > cases). Anything allocated from buddy allocator should be free of this problem, because MAX_ORDER is always smaller than a memory section size. This means majority of kernel code should be fine. What is left is core mm code that can have a chance to touch hugetlb, like migration, memory compaction, and of course hugetlb code. Yes, I did a manual code audit. And hopefully I caught all cases. An alternative is to use nth_page() everywhere, but that is a very invasive change for an uncommon config (SPARSEMEM + !VMEMMAP). -- Best Regards, Yan, Zi
Attachment:
signature.asc
Description: OpenPGP digital signature
