[PATCH v3] mm/page_isolation: fix potential missing call to unset_migratetype_isolate()

[PATCH v3] mm/page_isolation: fix potential missing call to unset_migratetype_isolate()

[Miaohe Lin]

In start_isolate_page_range() undo path, pfn_to_online_page() just checks
the first pfn in a pageblock while __first_valid_page() will traverse the
pageblock until the first online pfn is found. So we may miss the call to
unset_migratetype_isolate() in undo path and pages will remain isolated
unexpectedly. Fix this by calling undo_isolate_page_range() and this will
also help to simplify the code further. Note we shouldn't ever trigger it
because MAX_ORDER-1 aligned pfn ranges shouldn't contain memory holes now.

Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
v1->v2:
  Simplify the code further per David Hildenbrand.
v2->v3:
  remove unneeded cc stable.
---
 mm/page_isolation.c | 20 +++-----------------
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index a95c2c6562d0..f93cc63d8fa1 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -183,7 +183,6 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
 			     unsigned migratetype, int flags)
 {
 	unsigned long pfn;
-	unsigned long undo_pfn;
 	struct page *page;
 
 	BUG_ON(!IS_ALIGNED(start_pfn, pageblock_nr_pages));
@@ -193,25 +192,12 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
 	     pfn < end_pfn;
 	     pfn += pageblock_nr_pages) {
 		page = __first_valid_page(pfn, pageblock_nr_pages);
-		if (page) {
-			if (set_migratetype_isolate(page, migratetype, flags)) {
-				undo_pfn = pfn;
-				goto undo;
-			}
+		if (page && set_migratetype_isolate(page, migratetype, flags)) {
+			undo_isolate_page_range(start_pfn, pfn, migratetype);
+			return -EBUSY;
 		}
 	}
 	return 0;
-undo:
-	for (pfn = start_pfn;
-	     pfn < undo_pfn;
-	     pfn += pageblock_nr_pages) {
-		struct page *page = pfn_to_online_page(pfn);
-		if (!page)
-			continue;
-		unset_migratetype_isolate(page, migratetype);
-	}
-
-	return -EBUSY;
 }
 
 /*
-- 
2.23.0

Re: [PATCH v3] mm/page_isolation: fix potential missing call to unset_migratetype_isolate()

[David Hildenbrand]

On 14.09.21 13:43, Miaohe Lin wrote:
> In start_isolate_page_range() undo path, pfn_to_online_page() just checks
> the first pfn in a pageblock while __first_valid_page() will traverse the
> pageblock until the first online pfn is found. So we may miss the call to
> unset_migratetype_isolate() in undo path and pages will remain isolated
> unexpectedly. Fix this by calling undo_isolate_page_range() and this will
> also help to simplify the code further. Note we shouldn't ever trigger it
> because MAX_ORDER-1 aligned pfn ranges shouldn't contain memory holes now.
> 
> Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>

I read Michals reply, however, I am quite conservative with Fixes: tags. 
If there is nothing to fix, there is no BUG and the patch consequently 
merely a cleanup.

I'd have gone with a patch description/subject as follows:

"
mm/page_isolation: cleanup start_isolate_page_range()

We can heavily simplify the code by reusing undo_isolate_page_range().

Note that this also tackles a theoretical issue that would have been a 
real BUG before commit c5e79ef561b0 ("mm/memory_hotplug.c: don't allow 
to online/offline memory blocks with holes"). In 
start_isolate_page_range() undo path, pfn_to_online_page() just checks
the first pfn in a pageblock while __first_valid_page() will traverse 
the pageblock until the first online pfn is found. So we may miss the 
call to unset_migratetype_isolate() in undo path and pages will remain 
isolated unexpectedly.

Nowadays, start_isolate_page_range() never gets called on ranges that 
might contain memory holes. Consequently, this patch is not a fix but a 
cleanup.
"

Anyhow, whatever the other people prefer, no strong opinion.

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb

Re: [PATCH v3] mm/page_isolation: fix potential missing call to unset_migratetype_isolate()

[Miaohe Lin]

On 2021/9/15 2:13, David Hildenbrand wrote:
> On 14.09.21 13:43, Miaohe Lin wrote:
>> In start_isolate_page_range() undo path, pfn_to_online_page() just checks
>> the first pfn in a pageblock while __first_valid_page() will traverse the
>> pageblock until the first online pfn is found. So we may miss the call to
>> unset_migratetype_isolate() in undo path and pages will remain isolated
>> unexpectedly. Fix this by calling undo_isolate_page_range() and this will
>> also help to simplify the code further. Note we shouldn't ever trigger it
>> because MAX_ORDER-1 aligned pfn ranges shouldn't contain memory holes now.
>>
>> Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> 
> I read Michals reply, however, I am quite conservative with Fixes: tags. If there is nothing to fix, there is no BUG and the patch consequently merely a cleanup.
> 
> I'd have gone with a patch description/subject as follows:
> 
> "
> mm/page_isolation: cleanup start_isolate_page_range()
> 
> We can heavily simplify the code by reusing undo_isolate_page_range().
> 
> Note that this also tackles a theoretical issue that would have been a real BUG before commit c5e79ef561b0 ("mm/memory_hotplug.c: don't allow to online/offline memory blocks with holes"). In start_isolate_page_range() undo path, pfn_to_online_page() just checks
> the first pfn in a pageblock while __first_valid_page() will traverse the pageblock until the first online pfn is found. So we may miss the call to unset_migratetype_isolate() in undo path and pages will remain isolated unexpectedly.
> 
> Nowadays, start_isolate_page_range() never gets called on ranges that might contain memory holes. Consequently, this patch is not a fix but a cleanup.
> "
> 
> Anyhow, whatever the other people prefer, no strong opinion.

I have no preference too. But if this is preferred, I will do it.

> 
> Reviewed-by: David Hildenbrand <david@redhat.com>

Many thanks! :)

>