From: sashiko-bot@kernel.org
To: "Jiayuan Chen" <jiayuan.chen@linux.dev>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH v2 1/2] mm/damon/core: split a fraction of regions when nr_regions exceeds max/2
Date: Fri, 26 Jun 2026 09:09:15 +0000 [thread overview]
Message-ID: <20260626090915.73D161F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626085851.70754-2-jiayuan.chen@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Data race on the globally shared static variable `rotation` causes undefined behavior and inter-context interference.
--
commit 2895b546218b4ccc570b82e50e62f788bac4157b
Author: Jiayuan Chen <jiayuan.chen@shopee.com>
mm/damon/core: split a fraction of regions when nr_regions exceeds max/2
This commit modifies kdamond_split_regions() to split only a fraction of
regions rather than returning early when nr_regions is above max_nr_regions / 2.
It uses a rotating offset to ensure different regions are picked for splitting
over time as the region count smoothly approaches max_nr_regions.
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> +/* Split one in every @split_step regions into two, from a rotating offset */
> +static void damon_split_some_regions(struct damon_ctx *ctx,
> + unsigned long split_step)
> +{
> + static unsigned long rotation;
> + struct damon_target *t;
> + struct damon_region *r, *next;
> + unsigned long offset = rotation++ % split_step;
[Severity: Medium]
Will this cause a data race if multiple DAMON contexts are running concurrently?
Since rotation is declared static and locklessly incremented, independent
kdamond worker threads could read and mutate it simultaneously.
This unsynchronized read-modify-write on shared state might trigger automated
data race reports. Additionally, does this mean different contexts will step
on each other's rotation offsets, breaking the intended round-robin behavior
for each individual context?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626085851.70754-1-jiayuan.chen@linux.dev?part=1
next prev parent reply other threads:[~2026-06-26 9:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 8:58 [PATCH v2 0/2] mm/damon/core: detect internal variation above max_nr_regions/2 Jiayuan Chen
2026-06-26 8:58 ` [PATCH v2 1/2] mm/damon/core: split a fraction of regions when nr_regions exceeds max/2 Jiayuan Chen
2026-06-26 9:09 ` sashiko-bot [this message]
2026-06-26 14:49 ` SeongJae Park
2026-06-26 14:46 ` SeongJae Park
2026-06-26 8:58 ` [PATCH v2 2/2] mm/damon/tests/core-kunit: test split above max_nr_regions/2 Jiayuan Chen
2026-06-26 14:54 ` SeongJae Park
2026-06-26 14:59 ` [PATCH v2 0/2] mm/damon/core: detect internal variation " SeongJae Park
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=20260626090915.73D161F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=jiayuan.chen@linux.dev \
--cc=sashiko-reviews@lists.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.