Re: [PATCHv2 04/28] mm: make remove_migration_ptes() beyond mm/migration.c

From: Dave Hansen
Date: Tue Feb 16 2016 - 10:30:12 EST


On 02/16/2016 01:54 AM, Kirill A. Shutemov wrote:
> On Fri, Feb 12, 2016 at 08:54:58AM -0800, Dave Hansen wrote:
>> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote
>>> We also shouldn't try to mlock() pte-mapped huge pages: pte-mapeed THP
>>> pages are never mlocked.
>>
>> That's kinda subtle. Can you explain more?
>>
>> If we did the following:
>>
>> ptr = mmap(NULL, 512*PAGE_SIZE, ...);
>> mlock(ptr, 512*PAGE_SIZE);
>> fork();
>> munmap(ptr + 100 * PAGE_SIZE, PAGE_SIZE);
>>
>> I'd expect to get two processes, each mapping the same compound THP, one
>> with a PMD and the other with 511 ptes and one hole. Is there something
>> different that goes on?
>
> I'm not sure what exactly you want to ask with this code, but it will have
> the following result:
>
> - After fork() process will split the pmd in munlock(). For file thp
> split pmd, means clear it out. Mapping split_huge_pmd() would munlock
> the page as we do for anon thp;
>
> - In child process the page is never mapped as mlock() is not inherited
> and we don't copy page tables for shared VMA as they can re-faulted
> later;

Huh, I didn't realize we don't inherit mlock() across fork(). Learn
something every day!

> The basic semantic for mlock()ed file THP would be the same as for anon
> THP: we only keep the page mlocked as long as it's mapped only with PMDs.
> This way it's relatively simple to make sure that we don't leak mlocked
> pages.

Ahh, I forgot about that bit. Could you add some of that description to
the changelog so I don't forget again?