linux-kernel - Re: [PATCH 1/2] mm: gup: Re-pin pages in case of trying several times to migrate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b2b44837-045a-a5ac-319e-216f6b2491bb@linux.alibaba.com>
Date:   Thu, 20 Oct 2022 17:24:13 +0800
From:   Baolin Wang <baolin.wang@...ux.alibaba.com>
To:     "Huang, Ying" <ying.huang@...el.com>
Cc:     akpm@...ux-foundation.org, david@...hat.com, ziy@...dia.com,
        shy828301@...il.com, jingshan@...ux.alibaba.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mm: gup: Re-pin pages in case of trying several times
 to migrate



On 10/20/2022 4:15 PM, Huang, Ying wrote:
> Baolin Wang <baolin.wang@...ux.alibaba.com> writes:
> 
>> The migrate_pages() will return the number of {normal page, THP, hugetlb}
>> that were not migrated, or an error code. That means it can still return
>> the number of failure count, though the pages have been migrated
>> successfully with several times re-try.
> 
> If my understanding were correct, if pages are migrated successfully
> after several times re-tries, the return value will be 0.  There's one
> possibility for migrate_pages() to return non-zero but all pages are
> migrated.  That is, when THP is split and all subpages are migrated
> successfully.

Yeah, that's the case I tested. Thanks for pointing out. I'll re-write 
my incorrect commit message next time.

> 
>> So we should not use the return value of migrate_pages() to determin
>> if there are pages are failed to migrate. Instead we can validate the
>> 'movable_page_list' to see if there are pages remained in the list,
>> which are failed to migrate. That can mitigate the failure of longterm
>> pinning.
> 
> Another choice is to use a special return value for split THP + success
> migration.  But I'm fine to use list_empty(return_pages).

OK. Using list_empty(return_pages) looks more simple.

> 
>> Signed-off-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
>> ---
>>   mm/gup.c | 7 ++++---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index 5182aba..bd8cfcd 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -1914,9 +1914,10 @@ static int migrate_longterm_unpinnable_pages(
>>   			.gfp_mask = GFP_USER | __GFP_NOWARN,
>>   		};
>>   
>> -		if (migrate_pages(movable_page_list, alloc_migration_target,
>> -				  NULL, (unsigned long)&mtc, MIGRATE_SYNC,
>> -				  MR_LONGTERM_PIN, NULL)) {
>> +		ret = migrate_pages(movable_page_list, alloc_migration_target,
>> +				    NULL, (unsigned long)&mtc, MIGRATE_SYNC,
>> +				    MR_LONGTERM_PIN, NULL);
>> +		if (ret < 0 || !list_empty(movable_page_list)) {
> 
> It seems that !list_empty() is sufficient here.

OK. Drop the 'ret < 0'

>>   			ret = -ENOMEM;
> 
> Why change the error code?  I don't think it's a good idea to do that.

The GUP need a -errno for failure or partial success when migration, and 
we can not return the number of pages failed to migrate. So returning 
-ENOMEM seems suitable for both cases?