Re: [RFC PATCH v2 1/2] samples/damon/mtier: error out for zero quota goal target values

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:

New issues:
- [Low] The newly added comment incorrectly refers to `damos_quota_store()`=
 instead of `damos_quota_score()`.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the division-by-=
zero vulnerability is only patched at the module boundary in `mtier.c`. The=
 unvalidated core API (`damos_new_quota_goal` and `damos_quota_score`) rema=
ins vulnerable and is still exploitable via other DAMON components. For ins=
tance, in `mm/damon/lru_sort.c`, an unchecked `active_mem_bp` module parame=
ter can be set via sysfs such that it evaluates to 0, causing a kernel pani=
c.
--

--- Patch [1]: [RFC PATCH v2 1/2] samples/damon/mtier: error out for zero q=
uota goal target values ---
commit a29006e1d33ea981b557928c622fb8487e53dbc8
Author: SJ Park <[email protected]>
samples/damon/mtier: error out for zero quota goal target values

This commit prevents a division-by-zero exception in damos_quota_score() by
returning an error when users try to start DAMON with zero values for the
node0_mem_used_bp or node0_mem_free_bp parameters.

Link: https://lore.kernel.org/[email protected]

> diff --git a/samples/damon/mtier.c b/samples/damon/mtier.c
> index ac9c24b92ead8..d1123ebbfab90 100644
> --- a/samples/damon/mtier.c
> +++ b/samples/damon/mtier.c
> @@ -156,6 +156,9 @@ static struct damon_ctx *damon_sample_mtier_build_ctx=
(bool promote)
>  	if (!scheme)
>  		goto free_out;
>  	damon_set_schemes(ctx, &scheme, 1);
> +	/* zero target value causes division by zero in damos_quota_store() */

[Severity: Low]
This isn't a bug, but should this refer to damos_quota_score() instead of
damos_quota_store()?

> +	if (!node0_mem_used_bp || !node0_mem_free_bp)
> +		goto free_out;
>  	quota_goal =3D damos_new_quota_goal(

[Severity: High]
This isn't a bug introduced by this patch, but while this change handles the
zero target value at the module boundary in mtier.c, does the unvalidated
core API leave other DAMON components vulnerable?

For example, looking at damon_lru_sort_add_quota_goals() in
mm/damon/lru_sort.c:

    goal =3D damos_new_quota_goal(DAMOS_QUOTA_INACTIVE_MEM_BP,
                                10000 - active_mem_bp + 2);

If active_mem_bp is set to 10002 via sysfs, this evaluates to 0.

Because damos_new_quota_goal() in mm/damon/core.c accepts the target_value
without validation, this zero value propagates to damos_quota_score() where
mult_frac() performs a division by goal->target_value.

Could this cause a division by zero exception leading to a kernel panic?
Would it be safer to add validation directly inside damos_new_quota_goal()
or damos_quota_score() to protect all consumers?

>  			promote ? DAMOS_QUOTA_NODE_MEM_USED_BP :
>  			DAMOS_QUOTA_NODE_MEM_FREE_BP,
>  			promote ? node0_mem_used_bp : node0_mem_free_bp);

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260802162050.8947=
[email protected]?part=3D1