From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC39B337E82 for ; Wed, 17 Sep 2025 12:27:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758112056; cv=none; b=VajrtV+/CxJ0fzBDFj5FPLwEkI1xNRSY8RlO4ew8BeEZ//3ZoxoUuwr0hm8BPEz8fRyLPO+VqDn2NHmuqeaLDhnEgJqR9KvYeVTErBBS4r+GR/BWHeB20xBGmHXKHXUNTpffXlvOPG1EgWLn9BggfN9ceWhwSTe9x8lpr5sw848= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758112056; c=relaxed/simple; bh=DXFEV0L75NK8DITxIbJ6qV1/IjtmIINM9eo+5QDAZHw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Pu1J7K11XJiELS+3rANrN0fUFIUo/alK557r0GtTLX3g5eUOe9xyPrvFyLFqGoXGcRSa50kYKgETVvsGvsy7Lw1BZfNSQVvy0/zP9T0N/YHkJY1eG9PeHzsKqRo4zJB0ABIBP7gp/CyIDdBJAYRokk+lt2bXxUb5JtXXoTQrDmU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Wgryn0H3; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Wgryn0H3" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1758112052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9qjlcBWvXVjLJDUhAtJSvzuP30qgjG2/ZCnjDSBqbMg=; b=Wgryn0H33P8UysTg54ZpjWuLjfWsAt4PmDSksu+LiEiB2saOKADDVoBwCCc+kNyuc/nEt8 LsB1ToI91cgwN6UQmtQq/H4IxUN2RZUHfshkkq/Q7Hyr/jVnFlQNGxd3T72V153HtuaDUB brbJyccBio7DwPP7qAJb51BOasuNk/o= Date: Wed, 17 Sep 2025 20:27:15 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 1/3] mm/ksm: Fix incorrect KSM counter handling in mm_struct during fork To: Donet Tom , Andrew Morton , David Hildenbrand Cc: Ritesh Harjani , Xu Xin , Wei Yang , Aboorva Devarajan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Giorgi Tchankvetadze , stable@vger.kernel.org References: <4044e7623953d9f4c240d0308cf0b2fe769ee553.1757946863.git.donettom@linux.ibm.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <4044e7623953d9f4c240d0308cf0b2fe769ee553.1757946863.git.donettom@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2025/9/15 23:03, 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 inconsistent > accounting. > > When a process uses KSM, identical pages are merged and an rmap item is > created for each merged page. The `ksm_merging_pages` and > `ksm_rmap_items` counters are updated accordingly. However, after a > fork, these counters are copied to the child while the corresponding > rmap items are not. As a result, when the child later triggers an > unmerge, there are no rmap items present in the child, so the counters > remain stale, leading to incorrect accounting. > > A similar issue exists with `ksm_zero_pages`, which maintains both a > global counter and a per-process counter. During fork, the per-process > counter is inherited by the child, but the global counter is not > incremented. Since the child also references zero pages, the global > counter should be updated as well. Otherwise, during zero-page unmerge, > both the global and per-process counters are decremented, causing the > global counter to become inconsistent. > > To fix this, ksm_merging_pages and ksm_rmap_items are reset to 0 > during fork, and the global ksm_zero_pages counter is updated with the > per-process ksm_zero_pages value inherited by the child. This ensures > that KSM statistics remain accurate and reflect the activity of each > process correctly. > > Fixes: 7609385337a4 ("ksm: count ksm merging pages for each process") > Fixes: cb4df4cae4f2 ("ksm: count allocated ksm rmap_items for each process") > Fixes: e2942062e01d ("ksm: count all zero pages placed by KSM") > cc: stable@vger.kernel.org # v6.6 > Signed-off-by: Donet Tom Reviewed-by: Chengming Zhou Thanks. > --- > include/linux/ksm.h | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/include/linux/ksm.h b/include/linux/ksm.h > index 22e67ca7cba3..067538fc4d58 100644 > --- a/include/linux/ksm.h > +++ b/include/linux/ksm.h > @@ -56,8 +56,14 @@ 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)) { > + long nr_ksm_zero_pages = atomic_long_read(&mm->ksm_zero_pages); > + > + mm->ksm_merging_pages = 0; > + mm->ksm_rmap_items = 0; > + atomic_long_add(nr_ksm_zero_pages, &ksm_zero_pages); > __ksm_enter(mm); > + } > } > > static inline int ksm_execve(struct mm_struct *mm)