[PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork

[PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork

[Donet Tom]

Currently, the KSM-related counters in `mm_struct` such as
`ksm_merging_pages`, `ksm_rmap_items`, and `ksm_zero_pages` are
inherited by the child process during fork. This results in
incorrect accounting, since the child has not performed any
KSM page merging.

To fix this, reset these counters to 0 in the newly created
`mm_struct` during fork. This ensures that KSM statistics
remain accurate and only reflect the activity of each process.

Signed-off-by: Donet Tom <donettom@linux.ibm.com>
---
 include/linux/ksm.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index 22e67ca7cba3..61b8892c632b 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -56,8 +56,12 @@ static inline long mm_ksm_zero_pages(struct mm_struct *mm)
 static inline void ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
 {
 	/* Adding mm to ksm is best effort on fork. */
-	if (mm_flags_test(MMF_VM_MERGEABLE, oldmm))
+	if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) {
+		mm->ksm_merging_pages = 0;
+		mm->ksm_rmap_items = 0;
+		atomic_long_set(&mm->ksm_zero_pages, 0);
 		__ksm_enter(mm);
+	}
 }
 
 static inline int ksm_execve(struct mm_struct *mm)
-- 
2.51.0

[PATCH 2/2] selftests/mm: add fork inheritance test for ksm_merging_pages counter

[Donet Tom]

Add a new selftest to verify whether the `ksm_merging_pages` counter
in `mm_struct` is inherited by a child process after fork. This helps
ensure correctness of KSM accounting across process creation.

Signed-off-by: Donet Tom <donettom@linux.ibm.com>
---
 .../selftests/mm/ksm_functional_tests.c       | 42 ++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c b/tools/testing/selftests/mm/ksm_functional_tests.c
index 712f43c87736..d971394c9567 100644
--- a/tools/testing/selftests/mm/ksm_functional_tests.c
+++ b/tools/testing/selftests/mm/ksm_functional_tests.c
@@ -602,6 +602,45 @@ static void test_prot_none(void)
 	munmap(map, size);
 }
 
+static void test_fork_ksm_merging_page(void)
+{
+	const unsigned int size = 2 * MiB;
+	char *map;
+	pid_t child_pid;
+	int status;
+
+	ksft_print_msg("[RUN] %s\n", __func__);
+
+	map = mmap_and_merge_range(0xcf, size, PROT_READ | PROT_WRITE, KSM_MERGE_MADVISE);
+	if (map == MAP_FAILED)
+		return;
+
+	child_pid = fork();
+	if (!child_pid) {
+		int mpages;
+
+		init_global_file_handles();
+		mpages = ksm_get_self_merging_pages();
+		if (mpages > 0)
+			ksft_test_result_fail("ksm_merging_page in child: %d\n", mpages);
+
+		exit(0);
+	} else if (child_pid < 0) {
+		ksft_test_result_fail("fork() failed\n");
+		return;
+	}
+
+	if (waitpid(child_pid, &status, 0) < 0) {
+		ksft_test_result_fail("waitpid() failed\n");
+		return;
+	}
+
+	ksft_test_result_pass("ksm_merging_pages is not inherited after fork\n");
+
+	ksm_stop();
+	munmap(map, size);
+}
+
 static void init_global_file_handles(void)
 {
 	mem_fd = open("/proc/self/mem", O_RDWR);
@@ -620,7 +659,7 @@ static void init_global_file_handles(void)
 
 int main(int argc, char **argv)
 {
-	unsigned int tests = 8;
+	unsigned int tests = 9;
 	int err;
 
 	if (argc > 1 && !strcmp(argv[1], FORK_EXEC_CHILD_PRG_NAME)) {
@@ -652,6 +691,7 @@ int main(int argc, char **argv)
 	test_prctl_fork();
 	test_prctl_fork_exec();
 	test_prctl_unmerge();
+	test_fork_ksm_merging_page();
 
 	err = ksft_get_fail_cnt();
 	if (err)
-- 
2.51.0

Re: [PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork

[David Hildenbrand]

On 26.08.25 14:49, Donet Tom wrote:
> Currently, the KSM-related counters in `mm_struct` such as
> `ksm_merging_pages`, `ksm_rmap_items`, and `ksm_zero_pages` are
> inherited by the child process during fork. This results in
> incorrect accounting, since the child has not performed any
> KSM page merging.

So, the situation is that our child process maps these pages, but it 
does not have any stable rmap items corresponding to these pages.

rmap_walk_ksm() spells that case out.

Can you clarify that in the description here, and how both stats 
correspond to rmap items?

What is the effective result of this misacounting? I assume only a 
higher number than expected.

> 
> To fix this, reset these counters to 0 in the newly created
> `mm_struct` during fork. This ensures that KSM statistics
> remain accurate and only reflect the activity of each process.
> 

Fixes? CC stable?

> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> ---
>   include/linux/ksm.h | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/ksm.h b/include/linux/ksm.h
> index 22e67ca7cba3..61b8892c632b 100644
> --- a/include/linux/ksm.h
> +++ b/include/linux/ksm.h
> @@ -56,8 +56,12 @@ static inline long mm_ksm_zero_pages(struct mm_struct *mm)
>   static inline void ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
>   {
>   	/* Adding mm to ksm is best effort on fork. */
> -	if (mm_flags_test(MMF_VM_MERGEABLE, oldmm))
> +	if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) {
> +		mm->ksm_merging_pages = 0;
> +		mm->ksm_rmap_items = 0;
> +		atomic_long_set(&mm->ksm_zero_pages, 0);
>   		__ksm_enter(mm);
> +	}
>   }
>   
>   static inline int ksm_execve(struct mm_struct *mm)


-- 
Cheers

David / dhildenb

Re: [PATCH 2/2] selftests/mm: add fork inheritance test for ksm_merging_pages counter

[David Hildenbrand]

On 26.08.25 14:49, Donet Tom wrote:
> Add a new selftest to verify whether the `ksm_merging_pages` counter

"to verify ... is *not* inherited" ?

> in `mm_struct` is inherited by a child process after fork. This helps
> ensure correctness of KSM accounting across process creation.
> 
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> ---
>   .../selftests/mm/ksm_functional_tests.c       | 42 ++++++++++++++++++-
>   1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c b/tools/testing/selftests/mm/ksm_functional_tests.c
> index 712f43c87736..d971394c9567 100644
> --- a/tools/testing/selftests/mm/ksm_functional_tests.c
> +++ b/tools/testing/selftests/mm/ksm_functional_tests.c
> @@ -602,6 +602,45 @@ static void test_prot_none(void)
>   	munmap(map, size);
>   }
>   
> +static void test_fork_ksm_merging_page(void)
> +{
> +	const unsigned int size = 2 * MiB;
> +	char *map;
> +	pid_t child_pid;
> +	int status;
> +
> +	ksft_print_msg("[RUN] %s\n", __func__);
> +
> +	map = mmap_and_merge_range(0xcf, size, PROT_READ | PROT_WRITE, KSM_MERGE_MADVISE);
> +	if (map == MAP_FAILED)
> +		return;
> +
> +	child_pid = fork();
> +	if (!child_pid) {
> +		int mpages;
> +
> +		init_global_file_handles();
> +		mpages = ksm_get_self_merging_pages();
> +		if (mpages > 0)
> +			ksft_test_result_fail("ksm_merging_page in child: %d\n", mpages);
> +
> +		exit(0);
> +	} else if (child_pid < 0) {
> +		ksft_test_result_fail("fork() failed\n");
> +		return;
> +	}
> +
> +	if (waitpid(child_pid, &status, 0) < 0) {
> +		ksft_test_result_fail("waitpid() failed\n");
> +		return;
> +	}
> +
> +	ksft_test_result_pass("ksm_merging_pages is not inherited after fork\n");

Won't this trigger a fail in the child and a pass in the parent process?

You should likely instead let the child return the result (or the 
number) and check that here.

-- 
Cheers

David / dhildenb

Re: [PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork

[Giorgi Tchankvetadze]

What if we only allocate KSM stats when a process actually uses KSM?

struct ksm_mm_stats {
	atomic_long_t merging_pages;
	atomic_long_t rmap_items;
	atomic_long_t zero_pages;
};
struct ksm_mm_stats *mm->ksm_stats; // NULL until first enter

static inline struct ksm_mm_stats *mm_get_ksm_stats(struct mm_struct *mm)
{
	if (likely(mm->ksm_stats))
		return mm->ksm_stats;
	return ksm_alloc_stats_if_needed(mm); // Slow path
}



On 8/26/2025 4:49 PM, Donet Tom wrote:
> Currently, the KSM-related counters in `mm_struct` such as
> `ksm_merging_pages`, `ksm_rmap_items`, and `ksm_zero_pages` are
> inherited by the child process during fork. This results in
> incorrect accounting, since the child has not performed any
> KSM page merging.
> 
> To fix this, reset these counters to 0 in the newly created
> `mm_struct` during fork. This ensures that KSM statistics
> remain accurate and only reflect the activity of each process.
> 
> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
> ---
>   include/linux/ksm.h | 6 +++++-
>   1 filechanged <https://lore.kernel.org/linux-mm/2e662107e01417bf9af23bc7f52863cd538419be.1756211338.git.donettom@linux.ibm.com/#related>, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/ksm.h b/include/linux/ksm.h index 
> 22e67ca7cba3..61b8892c632b 100644 --- a/include/linux/ksm.h +++ b/ 
> include/linux/ksm.h @@ -56,8 +56,12 @@ static inline long 
> mm_ksm_zero_pages(struct mm_struct *mm)  static inline void ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
>   {
>   	/* Adding mm to ksm is best effort on fork. */
> - if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) + if 
> (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) { + mm->ksm_merging_pages = 0; 
> + mm->ksm_rmap_items = 0; + atomic_long_set(&mm->ksm_zero_pages, 0);  		__ksm_enter(mm);
> + }  }
>   
>   static inline int ksm_execve(struct mm_struct *mm)
> -- 
> 2.51.0
> 
> 

Re: [PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork

[David Hildenbrand]

On 26.08.25 15:47, Giorgi Tchankvetadze wrote:
> What if we only allocate KSM stats when a process actually uses KSM?
> 
> struct ksm_mm_stats {
> 	atomic_long_t merging_pages;
> 	atomic_long_t rmap_items;
> 	atomic_long_t zero_pages;
> };
> struct ksm_mm_stats *mm->ksm_stats; // NULL until first enter
> 
> static inline struct ksm_mm_stats *mm_get_ksm_stats(struct mm_struct *mm)
> {
> 	if (likely(mm->ksm_stats))
> 		return mm->ksm_stats;
> 	return ksm_alloc_stats_if_needed(mm); // Slow path
> }

The fork'ed child uses KSM. It just doesn't have any stable rmap entries.

We have to copy the zero_pages counter such that 
ksm_might_unmap_zero_page() will do the right thing.

But you're comment made me realize that there is likely another bug:

When copying zero_pages during fork(), we have to increment 
&ksm_zero_pages as well. Otherwise we will get an underflow later.

@Donet, can you look into that as well?

-- 
Cheers

David / dhildenb

Re: [PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork

[Donet Tom]

On 8/26/25 6:49 PM, David Hildenbrand wrote:
> On 26.08.25 14:49, Donet Tom wrote:
>> Currently, the KSM-related counters in `mm_struct` such as
>> `ksm_merging_pages`, `ksm_rmap_items`, and `ksm_zero_pages` are
>> inherited by the child process during fork. This results in
>> incorrect accounting, since the child has not performed any
>> KSM page merging.
>
> So, the situation is that our child process maps these pages, but it 
> does not have any stable rmap items corresponding to these pages.


Yes


>
> rmap_walk_ksm() spells that case out.
>
> Can you clarify that in the description here, and how both stats 
> correspond to rmap items?


Sure I will add it in next version.


>
> What is the effective result of this misacounting? I assume only a 
> higher number than expected.
>

Yes the number will be higher than expected.


>
>
>>
>> To fix this, reset these counters to 0 in the newly created
>> `mm_struct` during fork. This ensures that KSM statistics
>> remain accurate and only reflect the activity of each process.
>>
>
> Fixes? CC stable?


I will add it in next version.


>
>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>> ---
>>   include/linux/ksm.h | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/ksm.h b/include/linux/ksm.h
>> index 22e67ca7cba3..61b8892c632b 100644
>> --- a/include/linux/ksm.h
>> +++ b/include/linux/ksm.h
>> @@ -56,8 +56,12 @@ static inline long mm_ksm_zero_pages(struct 
>> mm_struct *mm)
>>   static inline void ksm_fork(struct mm_struct *mm, struct mm_struct 
>> *oldmm)
>>   {
>>       /* Adding mm to ksm is best effort on fork. */
>> -    if (mm_flags_test(MMF_VM_MERGEABLE, oldmm))
>> +    if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) {
>> +        mm->ksm_merging_pages = 0;
>> +        mm->ksm_rmap_items = 0;
>> +        atomic_long_set(&mm->ksm_zero_pages, 0);
>>           __ksm_enter(mm);
>> +    }
>>   }
>>     static inline int ksm_execve(struct mm_struct *mm)
>
>

Re: [PATCH 2/2] selftests/mm: add fork inheritance test for ksm_merging_pages counter

[Donet Tom]

Hi David

On 8/26/25 6:52 PM, David Hildenbrand wrote:
> On 26.08.25 14:49, Donet Tom wrote:
>> Add a new selftest to verify whether the `ksm_merging_pages` counter
>
> "to verify ... is *not* inherited" ?
>
I will change it in next version.

>
>
>> in `mm_struct` is inherited by a child process after fork. This helps
>> ensure correctness of KSM accounting across process creation.
>>
>> Signed-off-by: Donet Tom <donettom@linux.ibm.com>
>> ---
>>   .../selftests/mm/ksm_functional_tests.c       | 42 ++++++++++++++++++-
>>   1 file changed, 41 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c 
>> b/tools/testing/selftests/mm/ksm_functional_tests.c
>> index 712f43c87736..d971394c9567 100644
>> --- a/tools/testing/selftests/mm/ksm_functional_tests.c
>> +++ b/tools/testing/selftests/mm/ksm_functional_tests.c
>> @@ -602,6 +602,45 @@ static void test_prot_none(void)
>>       munmap(map, size);
>>   }
>>   +static void test_fork_ksm_merging_page(void)
>> +{
>> +    const unsigned int size = 2 * MiB;
>> +    char *map;
>> +    pid_t child_pid;
>> +    int status;
>> +
>> +    ksft_print_msg("[RUN] %s\n", __func__);
>> +
>> +    map = mmap_and_merge_range(0xcf, size, PROT_READ | PROT_WRITE, 
>> KSM_MERGE_MADVISE);
>> +    if (map == MAP_FAILED)
>> +        return;
>> +
>> +    child_pid = fork();
>> +    if (!child_pid) {
>> +        int mpages;
>> +
>> +        init_global_file_handles();
>> +        mpages = ksm_get_self_merging_pages();
>> +        if (mpages > 0)
>> +            ksft_test_result_fail("ksm_merging_page in child: %d\n", 
>> mpages);
>> +
>> +        exit(0);
>> +    } else if (child_pid < 0) {
>> +        ksft_test_result_fail("fork() failed\n");
>> +        return;
>> +    }
>> +
>> +    if (waitpid(child_pid, &status, 0) < 0) {
>> +        ksft_test_result_fail("waitpid() failed\n");
>> +        return;
>> +    }
>> +
>> +    ksft_test_result_pass("ksm_merging_pages is not inherited after 
>> fork\n");
>
> Won't this trigger a fail in the child and a pass in the parent process?
>
> You should likely instead let the child return the result (or the 
> number) and check that here.


Thanks for pointing this out. I will make the change in the next version

Re: [PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork

[Donet Tom]

On 8/26/25 7:39 PM, David Hildenbrand wrote:
> On 26.08.25 15:47, Giorgi Tchankvetadze wrote:
>> What if we only allocate KSM stats when a process actually uses KSM?
>>
>> struct ksm_mm_stats {
>>     atomic_long_t merging_pages;
>>     atomic_long_t rmap_items;
>>     atomic_long_t zero_pages;
>> };
>> struct ksm_mm_stats *mm->ksm_stats; // NULL until first enter
>>
>> static inline struct ksm_mm_stats *mm_get_ksm_stats(struct mm_struct 
>> *mm)
>> {
>>     if (likely(mm->ksm_stats))
>>         return mm->ksm_stats;
>>     return ksm_alloc_stats_if_needed(mm); // Slow path
>> }
>
> The fork'ed child uses KSM. It just doesn't have any stable rmap entries.
>
> We have to copy the zero_pages counter such that 
> ksm_might_unmap_zero_page() will do the right thing.
>
> But you're comment made me realize that there is likely another bug:
>
> When copying zero_pages during fork(), we have to increment 
> &ksm_zero_pages as well. Otherwise we will get an underflow later.


Yes, David, you are right. I added a test to check this scenario, and I 
am seeing ksm_zero_pages go negative.

# cat /sys/kernel/mm/ksm/ksm_zero_pages
-128
#


>
> @Donet, can you look into that as well?


Sure, I will add a fix for this issue in the next version.