lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f850ea7f-d2dc-4cc9-83ba-871d19311fa8@linux.ibm.com>
Date: Wed, 27 Aug 2025 23:33:05 +0530
From: Donet Tom <donettom@...ux.ibm.com>
To: David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc: Ritesh Harjani <ritesh.list@...il.com>, Xu Xin <xu.xin16@....com.cn>,
        Chengming Zhou <chengming.zhou@...ux.dev>,
        Wei Yang <richard.weiyang@...il.com>,
        Aboorva Devarajan <aboorvad@...ux.ibm.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mm/ksm: Reset KSM counters in mm_struct during fork


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@...ux.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)
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ