Re: [PATCH v10 07/38] dyndbg: factor ddebug_match_desc out from ddebug_change

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dyndbg: orphaned comment for ddebug_change applied to ddebug_match_desc
--

commit 09e57b269ce55ff151c63cc7e5d0dc659c6f52d5
Author: Jim Cromie <jim.cromie@gmail.com>

dyndbg: factor ddebug_match_desc out from ddebug_change

This commit factors out the per-descriptor matching logic from
ddebug_change into a new boolean function, ddebug_match_desc,
to simplify the inner loop.

> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index 49334d1aa4b3a..5187516c57a93 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -172,6 +172,60 @@ static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table cons
>   * callsites, normally the same as number of changes.  If verbose,
>   * logs the changes.  Takes ddebug_lock.
>   */
> +static bool ddebug_match_desc(const struct ddebug_query *query,
> +			      struct _ddebug *dp,
> +			      int valid_class)

[Severity: Low]
Does this placement separate the block comment from its intended target?

The comment describes a function that returns the number of matching callsites
and takes ddebug_lock, which accurately describes ddebug_change().

However, by inserting ddebug_match_desc() immediately after this comment,
does it leave ddebug_change() undocumented and make the comment falsely apply
to ddebug_match_desc() (which returns a bool and takes no locks)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916-dd-cmap-part2-clean-v10-0-af4cf4767707@gmail.com?part=7