On Tue, Aug 05, 2025 at 11:39:15AM +0530, Donet Tom wrote:
>
>On 8/4/25 2:41 PM, Wei Yang wrote:
>> On Tue, Jul 29, 2025 at 11:03:59AM +0530, Aboorva Devarajan wrote:
>> > From: Donet Tom <donet...@linux.ibm.com>
>> >
[...]
>> > diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c
>> > b/tools/testing/selftests/mm/ksm_functional_tests.c
>> > index d8bd1911dfc0..996dc6645570 100644
>> > --- a/tools/testing/selftests/mm/ksm_functional_tests.c
>> > +++ b/tools/testing/selftests/mm/ksm_functional_tests.c
>> > @@ -46,6 +46,8 @@ static int ksm_use_zero_pages_fd;
>> > static int pagemap_fd;
>> > static size_t pagesize;
>> >
>> > +static void init_global_file_handles(void);
>> > +
>> > static bool range_maps_duplicates(char *addr, unsigned long size)
>> > {
>> > unsigned long offs_a, offs_b, pfn_a, pfn_b;
>> > @@ -274,6 +276,7 @@ static void test_unmerge(void)
>> > ksft_test_result(!range_maps_duplicates(map, size),
>> > "Pages were unmerged\n");
>> > unmap:
>> > + ksm_unmerge();
>> In __mmap_and_merge_range(), we call ksm_unmerge(). Why this one not help?
>>
>> Not very familiar with ksm stuff. Would you mind giving more on how this fix
>> the failure you see?
>
>
>The issue I was facing here was test_prctl_fork was failing.
>
># [RUN] test_prctl_fork
># Still pages merged
>#
>
>This issue occurred because the previous test performed a merge, causing
>the value of /proc/self/ksm_merging_pages to reflect the number of
>deduplicated pages. After that, a fork() was called. Post-fork, the child
>process
>inherited the parent's ksm_merging_pages value.
>
Yes, this one is fixed by calling init_global_file_handles() in child.
>Then, the child process invoked __mmap_and_merge_range(), which resulted
>in unmerging the pages and resetting the value. However, since the parent
>process
>had performed the merge, its ksm_merging_pages value also got reset to 0.
>Meanwhile, the child process had not performed any merge itself, so the
>inherited
I assume the behavior described here is after the change to call
init_global_file_handles() in child.
Child process inherit the ksm_merging_pages from parent, which is reasonable
to me. But I am confused why ksm_unmerge() would just reset ksm_merging_pages
for parent and leave ksm_merging_pages in child process unchanged.
ksm_unmerge() writes to /sys/kernel/mm/ksm/run, which is a system wide sysfs
interface. I expect it applies to both parent and child.
>value remained unchanged. That’s why get_my_merging_page() in the child was
>returning a non-zero value.
>
I guess you mean the get_my_merging_page() in __mmap_and_merge_range() return
a non-zero value. But there is ksm_unmerge() before it. Why this ksm_unmerge()
couldn't reset the value, but a ksm_unmerge() in parent could.
>Initially, I fixed the issue by calling ksm_unmerge() before the fork(), and
>that
>resolved the problem. Later, I decided it would be cleaner to move the
>ksm_unmerge() call to the test cleanup phase.
>
Also all the tests before test_prctl_fork(), except test_prctl(), calls
ksft_test_result(!range_maps_duplicates());
If the previous tests succeed, it means there is no duplicate pages. This
means ksm_merging_pages should be 0 before test_prctl_fork() if other tests
pass. And the child process would inherit a 0 ksm_merging_pages. (A quick test
proves it.)
So which part of the story I missed?
--
Wei Yang
Help you, Help me
