On 8/8/19 4:41 PM, Ira Weiny wrote:
> On Thu, Aug 08, 2019 at 03:59:15PM -0700, John Hubbard wrote:
>> On 8/8/19 12:20 PM, John Hubbard wrote:
>>> On 8/8/19 4:09 AM, Vlastimil Babka wrote:
>>>> On 8/8/19 8:21 AM, Michal Hocko wrote:
>>>>> On Wed 07-08-19 16:32:08, John Hubbard wrote:
>>>>>> On 8/7/19 4:01 AM, Michal Hocko wrote:
>>>>>>> On Mon 05-08-19 15:20:17, john.hubbard@xxxxxxxxx wrote:
...
>> Oh, and meanwhile, I'm leaning toward a cheap fix: just use gup_fast() instead
>> of get_page(), and also fix the releasing code. So this incremental patch, on
>> top of the existing one, should do it:
>>
>> diff --git a/mm/mlock.c b/mm/mlock.c
>> index b980e6270e8a..2ea272c6fee3 100644
>> --- a/mm/mlock.c
>> +++ b/mm/mlock.c
>> @@ -318,18 +318,14 @@ static void __munlock_pagevec(struct pagevec *pvec, struct zone *zone)
>> /*
>> * We won't be munlocking this page in the next phase
>> * but we still need to release the follow_page_mask()
>> - * pin. We cannot do it under lru_lock however. If it's
>> - * the last pin, __page_cache_release() would deadlock.
>> + * pin.
>> */
>> - pagevec_add(&pvec_putback, pvec->pages[i]);
>> + put_user_page(pages[i]);
correction, make that:
put_user_page(pvec->pages[i]);
(This is not fully tested yet.)
>> pvec->pages[i] = NULL;
>> }
>> __mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
>> spin_unlock_irq(&zone->zone_pgdat->lru_lock);
>>
>> - /* Now we can release pins of pages that we are not munlocking */
>> - pagevec_release(&pvec_putback);
>> -
>
> I'm not an expert but this skips a call to lru_add_drain(). Is that ok?
Yes: unless I'm missing something, there is no reason to go through lru_add_drain
in this case. These are gup'd pages that are not going to get any further
processing.
>
>> /* Phase 2: page munlock */
>> for (i = 0; i < nr; i++) {
>> struct page *page = pvec->pages[i];
>> @@ -394,6 +390,8 @@ static unsigned long __munlock_pagevec_fill(struct pagevec *pvec,
>> start += PAGE_SIZE;
>> while (start < end) {
>> struct page *page = NULL;
>> + int ret;
>> +
>> pte++;
>> if (pte_present(*pte))
>> page = vm_normal_page(vma, start, *pte);
>> @@ -411,7 +409,13 @@ static unsigned long __munlock_pagevec_fill(struct pagevec *pvec,
>> if (PageTransCompound(page))
>> break;
>>
>> - get_page(page);
>> + /*
>> + * Use get_user_pages_fast(), instead of get_page() so that the
>> + * releasing code can unconditionally call put_user_page().
>> + */
>> + ret = get_user_pages_fast(start, 1, 0, &page);
>> + if (ret != 1)
>> + break;
>
> I like the idea of making this a get/put pair but I'm feeling uneasy about how
> this is really supposed to work.
>
> For sure the GUP/PUP was supposed to be separate from [get|put]_page.
>
Actually, they both take references on the page. And it is absolutely OK to call
them both on the same page.
But anyway, we're not mixing them up here. If you follow the code paths, either
gup or follow_page_mask() is used, and then put_user_page() releases.
So...you haven't actually pointed to a bug here, right? :)
thanks,
--
John Hubbard
NVIDIA
