Re: [RFC Patch 2/2] selftests/mm: assert rmap behave as expected

[David Hildenbrand <david@redhat.com>]

On 14.07.25 16:42, Wei Yang wrote:
> On Fri, Jul 11, 2025 at 05:39:39PM +0200, David Hildenbrand wrote:
>> On 04.06.25 10:34, Wei Yang wrote:
>>> On Wed, Jun 04, 2025 at 08:21:45AM +0000, Wei Yang wrote:
>>> [...]
>>>> +int try_to_move_page(char *region)
>>>> +{
>>>> +	int ret;
>>>> +	int node;
>>>> +	int status = 0;
>>>> +
>>>> +	ksft_print_msg("worker %d move_pages of content: %.15s\n", getpid(), region);
>>>
>>> One thing confused me here.
>>>
>>> If I don't access region here, the following move_pages() would report
>>> -ENOENT occationally. The reason is do_pages_stat_array() ->
>>> folio_walk_start() returns NULL.
>>
>> Right, the pages were not faulted in. The man page mentions that as
>>
>> "-ENOENT: The page is not present."
>>
> 
> Thanks I see the man page, but from the code point of view, I don't follow it.
> 
> The move_pages() return -ENOENT in a child process, and the child duplicate it
> memory space during fork().
> 
> dup_mmap()
>      for_each_vma()
>          copy_page_range()
> 	...
>              copy_pte_range() -> copy_present_ptes()
>                  __copy_present_ptes()
>                      set_ptes()
> 
> Even we map the range by MAP_SHARED, we don't need to wrprotect it.
> But we still set_ptes() in the child process page table.
> 
> 
> So it looks the child has prepared the page table and not need to fault in to
> setup it.
> 
> Do I miss something?

See copy_page_range() -> vma_needs_copy(), where we essentially 
optimize-out copying of page tables for most MAP_SHARED mappings (or 
MAP_PRIVATE mappings when we never placed private pages).

-- 
Cheers,

David / dhildenb