On 9/16/25 10:03 AM, Sasha Levin wrote:
On Mon, Sep 15, 2025 at 04:42:48PM -0700, Andrew Morton wrote:
On Mon, 15 Sep 2025 20:33:04 +0530 Donet Tom donettom@linux.ibm.com 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")
Linux-v5.19
Fixes: cb4df4cae4f2 ("ksm: count allocated ksm rmap_items for each process")
Linux-v6.1
Fixes: e2942062e01d ("ksm: count all zero pages placed by KSM")
Linux-v6.10
cc: stable@vger.kernel.org # v6.6
So how was Linux-v6.6 arrived at?
e2942062e01d is in v6.6, not in v6.10 - I suspect that this is why the "# v6.6" part was added.
Yes, e2942062e01d is in v6.6, which is why I mentioned that we need to backport it up to v6.6.
I think the most important use for Fixes: is to tell the -stable maintainers which kernel version(s) we believe should receive the patch. So listing multiple Fixes: targets just causes confusion.
Right - there's no way of communicating if all the commits listed in multiple Fixes tags should exist in the tree, or any one of them, for the new fix to be applicable.