[PATCH] mm: memory: use nth_page() in clear/copy_subpage()

[PATCH] mm: memory: use nth_page() in clear/copy_subpage()

[Kefeng Wang]

The clear and copy of huge gigantic page has converted to use nth_page()
to handle the possible discontinuous struct page(SPARSEMEM without VMEMMAP),
but not change for the non-gigantic part, fix it too.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 mm/memory.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 5c757fba8858..173b9b696230 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -6039,7 +6039,7 @@ static int clear_subpage(unsigned long addr, int idx, void *arg)
 {
 	struct page *page = arg;
 
-	clear_user_highpage(page + idx, addr);
+	clear_user_highpage(nth_page(page, idx), addr);
 	return 0;
 }
 
@@ -6089,10 +6089,11 @@ struct copy_subpage_arg {
 static int copy_subpage(unsigned long addr, int idx, void *arg)
 {
 	struct copy_subpage_arg *copy_arg = arg;
+	struct page *dst = nth_page(copy_arg->dst, idx);
+	struct page *src = nth_page(copy_arg->src, idx);
 
-	if (copy_mc_user_highpage(copy_arg->dst + idx, copy_arg->src + idx,
-				  addr, copy_arg->vma)) {
-		memory_failure_queue(page_to_pfn(copy_arg->src + idx), 0);
+	if (copy_mc_user_highpage(dst, src, addr, copy_arg->vma)) {
+		memory_failure_queue(page_to_pfn(src), 0);
 		return -EHWPOISON;
 	}
 	return 0;
-- 
2.41.0

Re: [PATCH] mm: memory: use nth_page() in clear/copy_subpage()

[Matthew Wilcox]

On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote:
> The clear and copy of huge gigantic page has converted to use nth_page()
> to handle the possible discontinuous struct page(SPARSEMEM without VMEMMAP),
> but not change for the non-gigantic part, fix it too.

Can there be discontiguities within a non-gigantic huge page?  My
impression was that you can't have a discontiguity at such a small
boundary.

Re: [PATCH] mm: memory: use nth_page() in clear/copy_subpage()

[David Hildenbrand]

On 29.12.23 09:49, Matthew Wilcox wrote:
> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote:
>> The clear and copy of huge gigantic page has converted to use nth_page()
>> to handle the possible discontinuous struct page(SPARSEMEM without VMEMMAP),
>> but not change for the non-gigantic part, fix it too.
> 
> Can there be discontiguities within a non-gigantic huge page?  My
> impression was that you can't have a discontiguity at such a small
> boundary.

No, we can't. MAX_ORDER allocations from the buddy always completely fit 
into a memory section.

-- 
Cheers,

David / dhildenb

Re: [PATCH] mm: memory: use nth_page() in clear/copy_subpage()

[Kefeng Wang]

On 2023/12/29 19:15, David Hildenbrand wrote:
> On 29.12.23 09:49, Matthew Wilcox wrote:
>> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote:
>>> The clear and copy of huge gigantic page has converted to use nth_page()
>>> to handle the possible discontinuous struct page(SPARSEMEM without 
>>> VMEMMAP),
>>> but not change for the non-gigantic part, fix it too.
>>
>> Can there be discontiguities within a non-gigantic huge page?  My
>> impression was that you can't have a discontiguity at such a small
>> boundary.
> 
> No, we can't. MAX_ORDER allocations from the buddy always completely fit 
> into a memory section.

On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section,
right?

But after v5.13 commit 782276b4d0ad ("arm64: Force SPARSEMEM_VMEMMAP
as the only memory management model"), it looks only old lts, eg, 5.10 
could meet this issue.

Re: [PATCH] mm: memory: use nth_page() in clear/copy_subpage()

[David Hildenbrand]

On 02.01.24 07:53, Kefeng Wang wrote:
> 
> 
> On 2023/12/29 19:15, David Hildenbrand wrote:
>> On 29.12.23 09:49, Matthew Wilcox wrote:
>>> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote:
>>>> The clear and copy of huge gigantic page has converted to use nth_page()
>>>> to handle the possible discontinuous struct page(SPARSEMEM without
>>>> VMEMMAP),
>>>> but not change for the non-gigantic part, fix it too.
>>>
>>> Can there be discontiguities within a non-gigantic huge page?  My
>>> impression was that you can't have a discontiguity at such a small
>>> boundary.
>>
>> No, we can't. MAX_ORDER allocations from the buddy always completely fit
>> into a memory section.
> 
> On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section,
> right?

I recall the mem sections are always at least 128 MiB on arm64.

Note that anything > MAX_ORDER is called a "gigantic huge page" in 
hugetlb code.


-- 
Cheers,

David / dhildenb

Re: [PATCH] mm: memory: use nth_page() in clear/copy_subpage()

[Kefeng Wang]

On 2024/1/3 0:11, David Hildenbrand wrote:
> On 02.01.24 07:53, Kefeng Wang wrote:
>>
>>
>> On 2023/12/29 19:15, David Hildenbrand wrote:
>>> On 29.12.23 09:49, Matthew Wilcox wrote:
>>>> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote:
>>>>> The clear and copy of huge gigantic page has converted to use 
>>>>> nth_page()
>>>>> to handle the possible discontinuous struct page(SPARSEMEM without
>>>>> VMEMMAP),
>>>>> but not change for the non-gigantic part, fix it too.
>>>>
>>>> Can there be discontiguities within a non-gigantic huge page?  My
>>>> impression was that you can't have a discontiguity at such a small
>>>> boundary.
>>>
>>> No, we can't. MAX_ORDER allocations from the buddy always completely fit
>>> into a memory section.
>>
>> On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section,
>> right?
> 
> I recall the mem sections are always at least 128 MiB on arm64.
> 
> Note that anything > MAX_ORDER is called a "gigantic huge page" in 
> hugetlb code.

Yes, we already check MAX_ORDER, please ignore this one, thanks.

> 
>