From: Zi Yan ziy@nvidia.com
When dealing with hugetlb pages, manipulating struct page pointers directly can get to wrong struct page, since struct page is not guaranteed to be contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it properly.
Fixes: eeb0efd071d8 ("mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages") Cc: stable@vger.kernel.org Signed-off-by: Zi Yan ziy@nvidia.com Reviewed-by: Muchun Song songmuchun@bytedance.com --- mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 1b03f4ec6fd2..3b301c4023ff 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1689,7 +1689,7 @@ static int scan_movable_pages(unsigned long start, unsigned long end, */ if (HPageMigratable(head)) goto found; - skip = compound_nr(head) - (page - head); + skip = compound_nr(head) - (pfn - page_to_pfn(head)); pfn += skip - 1; } return -ENOENT;
On 06.09.23 17:03, Zi Yan wrote:
From: Zi Yan ziy@nvidia.com
Subject talks about "nth_page()" but that's not what this patch does.
When dealing with hugetlb pages, manipulating struct page pointers directly can get to wrong struct page, since struct page is not guaranteed to be contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it properly.
^ dito
Fixes: eeb0efd071d8 ("mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages") Cc: stable@vger.kernel.org Signed-off-by: Zi Yan ziy@nvidia.com Reviewed-by: Muchun Song songmuchun@bytedance.com
mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 1b03f4ec6fd2..3b301c4023ff 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1689,7 +1689,7 @@ static int scan_movable_pages(unsigned long start, unsigned long end, */ if (HPageMigratable(head)) goto found;
skip = compound_nr(head) - (page - head);
pfn += skip - 1; } return -ENOENT;skip = compound_nr(head) - (pfn - page_to_pfn(head));
I suspect systems without VMEMMAP also don't usually support gigantic pages AND hotunplug :)
With the subject+description fixed
Acked-by: David Hildenbrand david@redhat.com
On 6 Sep 2023, at 13:17, David Hildenbrand wrote:
On 06.09.23 17:03, Zi Yan wrote:
From: Zi Yan ziy@nvidia.com
Subject talks about "nth_page()" but that's not what this patch does.
When dealing with hugetlb pages, manipulating struct page pointers directly can get to wrong struct page, since struct page is not guaranteed to be contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it properly.
^ dito
Fixes: eeb0efd071d8 ("mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages") Cc: stable@vger.kernel.org Signed-off-by: Zi Yan ziy@nvidia.com Reviewed-by: Muchun Song songmuchun@bytedance.com
mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 1b03f4ec6fd2..3b301c4023ff 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1689,7 +1689,7 @@ static int scan_movable_pages(unsigned long start, unsigned long end, */ if (HPageMigratable(head)) goto found;
skip = compound_nr(head) - (page - head);
pfn += skip - 1; } return -ENOENT;skip = compound_nr(head) - (pfn - page_to_pfn(head));
I suspect systems without VMEMMAP also don't usually support gigantic pages AND hotunplug :)
With the subject+description fixed
Acked-by: David Hildenbrand david@redhat.com
Sure. Thanks.
-- Best Regards, Yan, Zi
On 6 Sep 2023, at 11:03, Zi Yan wrote:
From: Zi Yan ziy@nvidia.com
When dealing with hugetlb pages, manipulating struct page pointers directly can get to wrong struct page, since struct page is not guaranteed to be contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it properly.
Fixes: eeb0efd071d8 ("mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages") Cc: stable@vger.kernel.org Signed-off-by: Zi Yan ziy@nvidia.com Reviewed-by: Muchun Song songmuchun@bytedance.com
mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 1b03f4ec6fd2..3b301c4023ff 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1689,7 +1689,7 @@ static int scan_movable_pages(unsigned long start, unsigned long end, */ if (HPageMigratable(head)) goto found;
skip = compound_nr(head) - (page - head);
pfn += skip - 1; } return -ENOENT;skip = compound_nr(head) - (pfn - page_to_pfn(head));
-- 2.40.1
Fixed the subject and commit message:
From: Zi Yan ziy@nvidia.com Date: Wed, 6 Sep 2023 10:51:21 -0400 Subject: [PATCH v2 3/5] mm/memory_hotplug: use pfn calculation in place of direct struct page manipulation.
When dealing with hugetlb pages, manipulating struct page pointers directly can get to wrong struct page, since struct page is not guaranteed to be contiguous on SPARSEMEM without VMEMMAP. Use pfn calculation to handle it properly.
Fixes: eeb0efd071d8 ("mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages") Cc: stable@vger.kernel.org Signed-off-by: Zi Yan ziy@nvidia.com Reviewed-by: Muchun Song songmuchun@bytedance.com Acked-by: David Hildenbrand david@redhat.com --- mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 1b03f4ec6fd2..3b301c4023ff 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1689,7 +1689,7 @@ static int scan_movable_pages(unsigned long start, unsigned long end, */ if (HPageMigratable(head)) goto found; - skip = compound_nr(head) - (page - head); + skip = compound_nr(head) - (pfn - page_to_pfn(head)); pfn += skip - 1; } return -ENOENT; -- 2.40.1
-- Best Regards, Yan, Zi
linux-stable-mirror@lists.linaro.org