Re: [PATCH v10 07/38] dyndbg: factor ddebug_match_desc out from ddebug_change
From: sashiko-bot@kernel.org
Date: 2026-09-16 15:47:06
Also in:
dri-devel
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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