| Message ID | 20230906150309.114360-1-zi.yan@sent.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Use nth_page() in place of direct struct page manipulation | expand |
Hi, On 6/9/23 17:03, Zi Yan wrote: > From: Zi Yan <ziy@nvidia.com> > > 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). Thanks, Phil.
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@nvidia.com> >> >> 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
From: Zi Yan <ziy@nvidia.com> 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. The patches are on top of next-20230906 Changes from v1: 1. Separated first patch into three and add Fixes for better backport. 2. Collected Reviewed-by. Zi Yan (5): mm/cma: use nth_page() in place of direct struct page manipulation. mm/hugetlb: use nth_page() in place of direct struct page manipulation. mm/memory_hotplug: use nth_page() in place of direct struct page manipulation. fs: use nth_page() in place of direct struct page manipulation. mips: use nth_page() in place of direct struct page manipulation. arch/mips/mm/cache.c | 2 +- fs/hugetlbfs/inode.c | 4 ++-- mm/cma.c | 2 +- mm/hugetlb.c | 2 +- mm/memory_hotplug.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-)