Re: [RFC PATCH v2.2 02/28] mm/damon/core: embed damon_probe objects in damon_ctx

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing parentheses around the `ctx` macro argument in `damon_for_each_probe` and `damon_for_each_probe_safe`.
--

commit e24428c998724cd2c79829fc347f7cc9804f966b
Author: SeongJae Park <sj@kernel.org>

mm/damon/core: embed damon_probe objects in damon_ctx

This commit adds a linked list of damon_probe objects to damon_ctx. It also
introduces initialization, cleanup, and helper macros to iterate over the new
list.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index a8fff5325b010..3ba5a31b51769 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h

[ ... ]

> @@ -879,6 +880,11 @@ static inline unsigned long damon_sz_region(struct damon_region *r)
>  	return r->ar.end - r->ar.start;
>  }
>  
> +#define damon_for_each_probe(p, ctx) \
> +	list_for_each_entry(p, &ctx->probes, list)
> +
> +#define damon_for_each_probe_safe(p, next, ctx) \
> +	list_for_each_entry_safe(p, next, &ctx->probes, list)

Should the ctx macro argument be wrapped in parentheses here?

Due to C operator precedence, if a caller passes an expression requiring a
cast like (struct damon_ctx *)ptr, the macro would expand to:

    &(struct damon_ctx *)ptr->probes

Because the member access operator -> binds tighter than the cast, this
evaluates as &(struct damon_ctx *)(ptr->probes). This can lead to
unexpected compilation errors or incorrect pointer arithmetic.

Wrapping it as &(ctx)->probes would safely isolate the argument and match
the pattern used by the existing damon_for_each_scheme macro in this file.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515004433.128933-1-sj@kernel.org?part=2