From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH v3 1/2] mm/damon/core: split a fraction of regions when nr_regions exceeds max/2
Date: Mon, 29 Jun 2026 15:08:10 +0000 [thread overview]
Message-ID: <20260629150812.065511F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629145630.134891-2-sj@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Cross-context state corruption and data races due to the use of a static local variable `rotation`.
--
commit 696204689b6ff0a9b6ca3153698c49bfe10cff24
Author: Jiayuan Chen <jiayuan.chen@shopee.com>
mm/damon/core: split a fraction of regions when nr_regions exceeds max/2
This commit modifies the kdamond_split_regions logic to split only a fraction
of regions when the region count exceeds half the maximum, rather than
returning early. It uses a rotating offset to select which regions to split,
refining the count smoothly as it approaches the maximum.
Link: https://lore.kernel.org/20260626085851.70754-2-jiayuan.chen@linux.dev
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 027250e43c66f..9bbc60a2a8c05 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -3234,6 +3234,37 @@ static void damon_split_regions_of(struct damon_ctx *ctx,
> }
> }
>
> +/* 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 shared static variable cause data races and logic flaws if
multiple DAMON contexts are active?
Since rotation is declared statically, multiple kdamond threads could
concurrently increment it without synchronization. This might lead to
data races and cause different contexts to overwrite each other's
rotation offsets, breaking the isolation of the splitting algorithm and
resulting in uneven or skipped splits in some contexts.
Should this state be kept per-context instead of using a static local
variable?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629145630.134891-1-sj@kernel.org?part=1
next prev parent reply other threads:[~2026-06-29 15:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 14:56 [PATCH v3 0/2] mm/damon/core: detect internal variation above max_nr_regions/2 SJ Park
2026-06-29 14:56 ` [PATCH v3 1/2] mm/damon/core: split a fraction of regions when nr_regions exceeds max/2 SJ Park
2026-06-29 15:08 ` sashiko-bot [this message]
2026-06-30 0:19 ` SJ Park
2026-06-29 14:56 ` [PATCH v3 2/2] mm/damon/tests/core-kunit: test split above max_nr_regions/2 SJ 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=20260629150812.065511F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sj@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox