Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:
> On Tue, 31 Jan 2023 14:32:06 +0800 Kuan-Ying Lee <Kuan-Ying.Lee@xxxxxxxxxxxx> wrote:
>
>> If we call folio_isolate_lru() successfully, we will get
>> return value 0. We need to add this folio to the
>> movable_pages_list.
Ugh, thanks for catching this:
Reviewed-by: Alistair Popple <apopple@xxxxxxxxxx>
>> Fixes: 67e139b02d99 ("mm/gup.c: refactor check_and_migrate_movable_pages()")
>> Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@xxxxxxxxxxxx>
>>
>> ...
>>
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -1914,7 +1914,7 @@ static unsigned long collect_longterm_unpinnable_pages(
>> drain_allow = false;
>> }
>>
>> - if (!folio_isolate_lru(folio))
>> + if (folio_isolate_lru(folio))
>> continue;
>>
>> list_add_tail(&folio->lru, movable_page_list);
>
> Thanks. What are the user-visible effects of this bug?
In the common case none other than an extra loop through
collect_longterm_unpinnable_pages():
1. First call to collect_longterm_unpinnable_pages() will increment
collected and isolate the page but not add it to movable_page_list.
2. migrate_longterm_unpinnable_pages() will return -EAGAIN and unpin all
the pages but they will remain LRU isolated.
3. The next spin around __gup_longterm_locked() will re-pin the pages
and re-call collect_longterm_unpinnable_pages(). As the page has
already been isolated folio_isolate_lru() will return -EBUSY which
will add the page to movable_page_list and complete processing as
intended.
However this assumes the page table still points to the same page when
__get_user_pages_locked() is called the second time. That may not be the
case in which case we would leave the page LRU isolated forever
effectively leaving an unmovable page in a movable zone which is what we
were trying to avoid in the first place.
So I think Cc: stable is warranted.
- Alistair
