[PATCH 0/3] Use nth_page() in place of direct struct page manipulation

[PATCH 0/3] Use nth_page() in place of direct struct page manipulation

[Zi Yan]

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-20230830.

Zi Yan (3):
  mm: 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(-)

-- 
2.40.1

[PATCH 1/3] mm: use nth_page() in place of direct struct page manipulation.

[Zi Yan]

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.

Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 mm/cma.c            | 2 +-
 mm/hugetlb.c        | 2 +-
 mm/memory_hotplug.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/cma.c b/mm/cma.c
index da2967c6a223..2b2494fd6b59 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -505,7 +505,7 @@ struct page *cma_alloc(struct cma *cma, unsigned long count,
 	 */
 	if (page) {
 		for (i = 0; i < count; i++)
-			page_kasan_tag_reset(page + i);
+			page_kasan_tag_reset(nth_page(page, i));
 	}
 
 	if (ret && !no_warn) {
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ba6d39b71cb1..77e8d2cf4eed 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6474,7 +6474,7 @@ struct page *hugetlb_follow_page_mask(struct vm_area_struct *vma,
 			}
 		}
 
-		page += ((address & ~huge_page_mask(h)) >> PAGE_SHIFT);
+		page = nth_page(page, ((address & ~huge_page_mask(h)) >> PAGE_SHIFT));
 
 		/*
 		 * Note that page may be a sub-page, and with vmemmap
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

[PATCH 2/3] fs: use nth_page() in place of direct struct page manipulation.

[Zi Yan]

From: Zi Yan <ziy@nvidia.com>

When dealing with hugetlb pages, struct page is not guaranteed to be
contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it
properly.

Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 fs/hugetlbfs/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 316c4cebd3f3..60fce26ff937 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -295,7 +295,7 @@ static size_t adjust_range_hwpoison(struct page *page, size_t offset, size_t byt
 	size_t res = 0;
 
 	/* First subpage to start the loop. */
-	page += offset / PAGE_SIZE;
+	page = nth_page(page, offset / PAGE_SIZE);
 	offset %= PAGE_SIZE;
 	while (1) {
 		if (is_raw_hwpoison_page_in_hugepage(page))
@@ -309,7 +309,7 @@ static size_t adjust_range_hwpoison(struct page *page, size_t offset, size_t byt
 			break;
 		offset += n;
 		if (offset == PAGE_SIZE) {
-			page++;
+			page = nth_page(page, 1);
 			offset = 0;
 		}
 	}
-- 
2.40.1

[PATCH 3/3] mips: use nth_page() in place of direct struct page manipulation.

[Zi Yan]

From: Zi Yan <ziy@nvidia.com>

__flush_dcache_pages() is called during hugetlb migration via
migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page()
-> move_to_new_folio() -> flush_dcache_folio(). And with hugetlb and
without sparsemem vmemmap, struct page is not guaranteed to be contiguous
beyond a section. Use nth_page() instead.

Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 arch/mips/mm/cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 02042100e267..7f830634dbe7 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -117,7 +117,7 @@ void __flush_dcache_pages(struct page *page, unsigned int nr)
 	 * get faulted into the tlb (and thus flushed) anyways.
 	 */
 	for (i = 0; i < nr; i++) {
-		addr = (unsigned long)kmap_local_page(page + i);
+		addr = (unsigned long)kmap_local_page(nth_page(page, i));
 		flush_data_cache_page(addr);
 		kunmap_local((void *)addr);
 	}
-- 
2.40.1

Re: [PATCH 1/3] mm: use nth_page() in place of direct struct page manipulation.

[Muchun Song]

> On Aug 31, 2023, at 02:27, Zi Yan <zi.yan@sent.com> 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.
> 
> Signed-off-by: Zi Yan <ziy@nvidia.com>

Reviewed-by: Muchun Song <songmuchun@bytedance.com>

Maybe 3 separate patches would be better for backporting purpose.

Re: [PATCH 2/3] use nth_page() in place of direct struct page manipulation.

[Muchun Song]

> On Aug 31, 2023, at 02:27, Zi Yan <zi.yan@sent.com> wrote:
> 
> From: Zi Yan <ziy@nvidia.com>
> 
> When dealing with hugetlb pages, struct page is not guaranteed to be
> contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it
> properly.
> 
> Signed-off-by: Zi Yan <ziy@nvidia.com <mailto:ziy@nvidia.com>>

Reviewed-by: Muchun Song <songmuchun@bytedance.com>

It's better to add a Fixes tag to the commit 38c1ddbde6.

Thanks.

Re: [PATCH 2/3] use nth_page() in place of direct struct page manipulation.

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On 31 Aug 2023, at 3:17, Muchun Song wrote:

>> On Aug 31, 2023, at 02:27, Zi Yan <zi.yan@sent.com> wrote:
>>
>> From: Zi Yan <ziy@nvidia.com>
>>
>> When dealing with hugetlb pages, struct page is not guaranteed to be
>> contiguous on SPARSEMEM without VMEMMAP. Use nth_page() to handle it
>> properly.
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com <mailto:ziy@nvidia.com>>
>
> Reviewed-by: Muchun Song <songmuchun@bytedance.com>
>
> It's better to add a Fixes tag to the commit 38c1ddbde6.

Thanks. Will add it in the next version.

--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

Re: [PATCH 1/3] mm: use nth_page() in place of direct struct page manipulation.

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On 31 Aug 2023, at 3:14, Muchun Song wrote:

>> On Aug 31, 2023, at 02:27, Zi Yan <zi.yan@sent.com> 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.
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>
> Reviewed-by: Muchun Song <songmuchun@bytedance.com>
>
> Maybe 3 separate patches would be better for backporting purpose.
Sure. Will split it and add Fixes in the next version.

--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]