From: sashiko-bot@kernel.org
To: xu.xin@linux.dev, "Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>
Cc: "Chengming Zhou" <chengming.zhou@linux.dev>,
"Lorenzo Stoakes" <lstoakes@gmail.com>,
"Liam R . Howlett" <liam.howlett@oracle.com>,
linux-mm@kvack.org, "Huan Yang" <link@vivo.com>,
"Wang Xiao" <xiao.wang@vivo.com>
Subject: Re: [PATCH resend] ksm: add merge_only_zero_pages to merge only empty anonymous pages
Date: Sat, 07 Nov 2026 03:49:32 +0000 [thread overview]
Message-ID: <sashiko-outbox-202537@kernel.org> (raw)
In-Reply-To: <20261106034841.233085-1-xu.xin@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm: ksm: unsynchronized state checks in zero-page sysfs store
handlers
--
commit 9b8576e88012c85cc90e3b5aa732dfb204eefebc
Author: Xu Xin (vivo) <xu.xin@linux.dev>
ksm: add merge_only_zero_pages to merge only empty anonymous pages
This commit adds the /sys/kernel/mm/ksm/merge_only_zero_pages sysfs attribute
so ksmd can merge only zero-filled anonymous pages with the kernel zero page
while skipping the stable and unstable trees for pages carrying data.
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 340c65aa14e58..35ed40747e30e 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
[ ... ]
> @@ -3679,12 +3695,48 @@ static ssize_t use_zero_pages_store(struct kobject *kobj,
> if (err)
> return -EINVAL;
>
> + /*
> + * merge_only_zero_pages depends on use_zero_pages: refuse to turn
> + * the latter off while the former is active, so the two cannot
> + * silently diverge.
> + */
> + if (!value && ksm_merge_only_zero_pages)
> + return -EBUSY;
> +
> ksm_use_zero_pages = value;
>
> return count;
> }
> KSM_ATTR(use_zero_pages);
>
> +static ssize_t merge_only_zero_pages_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + return sysfs_emit(buf, "%u\n", ksm_merge_only_zero_pages);
> +}
> +static ssize_t merge_only_zero_pages_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int err;
> + bool value;
> +
> + err = kstrtobool(buf, &value);
> + if (err)
> + return -EINVAL;
> +
> + if (value && !ksm_use_zero_pages) {
> + pr_warn_once("ksm: merge_only_zero_pages can only be enabled "
> + "when use_zero_pages is 1\n");
> + return -EINVAL;
> + }
> +
> + ksm_merge_only_zero_pages = value;
[Severity: Medium]
Can concurrent writes to use_zero_pages and merge_only_zero_pages cause
ksm_use_zero_pages and ksm_merge_only_zero_pages to diverge?
Since these are separate sysfs attributes, kernfs does not serialize
use_zero_pages_store() against merge_only_zero_pages_store(), and neither
handler takes ksm_thread_mutex or another shared lock.
Starting from ksm_use_zero_pages == true and ksm_merge_only_zero_pages ==
false, if one task writes 0 to use_zero_pages while another concurrently
writes 1 to merge_only_zero_pages:
CPU 0 CPU 1
use_zero_pages_store() merge_only_zero_pages_store()
if (!value && if (value &&
ksm_merge_only_zero_pages) !ksm_use_zero_pages)
/* sees false */ /* sees true */
ksm_use_zero_pages = false; ksm_merge_only_zero_pages = true;
With ksm_use_zero_pages set to false and ksm_merge_only_zero_pages set to
true, try_to_merge_with_zero_page() always returns -EFAULT and the
subsequent ksm_merge_only_zero_pages check in cmp_and_merge_page() returns
early:
mm/ksm.c:cmp_and_merge_page() {
...
if (!try_to_merge_with_zero_page(rmap_item, page))
return;
if (ksm_merge_only_zero_pages)
return;
...
}
Wouldn't this leave ksmd scanning and checksumming pages without ever
merging either zero pages or non-zero pages?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106034841.233085-1-xu.xin@linux.dev?part=1
next prev parent reply other threads:[~2026-11-07 3:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 3:48 [PATCH resend] ksm: add merge_only_zero_pages to merge only empty anonymous pages xu.xin
2026-11-07 3:49 ` sashiko-bot [this message]
2026-11-07 8:13 ` Jinjiang Tu
2026-11-09 2:02 ` Xu Xin (vivo)
2026-11-09 3:17 ` Jinjiang Tu
2026-11-09 17:56 ` David Hildenbrand (Arm)
2026-11-09 7:58 ` Xu Xin (vivo)
2026-11-10 2:02 ` Jinjiang Tu
2026-11-07 18:28 ` David Hildenbrand (Arm)
2026-11-09 1:39 ` Xu Xin (vivo)
2026-11-09 17:41 ` David Hildenbrand (Arm)
2026-11-10 1:34 ` Xu Xin (vivo)
2026-11-10 11:54 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-202537@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=liam.howlett@oracle.com \
--cc=link@vivo.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=xiao.wang@vivo.com \
--cc=xu.xin@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.