Re: [PATCH v10 25/38] dyndbg: detect class_id reservation conflicts
From: sashiko-bot@kernel.org
Date: 2026-09-16 16:30:56
Also in:
dri-devel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] dyndbg: unconditional mod_ct increment leads to inaccurate initialization logs -- commit d123ad70c52a21eda06f63a98463a51685d0bfb6 Author: Jim Cromie [off-list ref] dyndbg: detect class_id reservation conflicts If a module _DEFINEs 2 or more classmaps, it must devise them to share the per-module 0..62 class-id space; ie their respective base,+length reservations cannot overlap.
quoted hunk ↗ jump to hunk
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 566c3860d7bfb..7736fb3d3b791 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -1605,7 +1617,7 @@ static int __init dynamic_debug_init(void) di.mod_name = modname; ret = ddebug_add_module(&di); if (ret) - goto out_err; + pr_warn("failed to add built-in module %s: %d\n", modname, ret); mod_ct++;
[Severity: Low] Is it intentional to unconditionally increment mod_ct here? By changing this from a fatal error to a warn-and-continue, if ddebug_add_module() fails, the inflated mod_ct will cause inaccurate initialization logs (vpr_info) and an incorrect calculation for memory used by ddebug tables. Should the increment only happen on success?
quoted hunk ↗ jump to hunk
@@ -1620,7 +1632,7 @@ static int __init dynamic_debug_init(void) di.mod_name = modname; ret = ddebug_add_module(&di); if (ret) - goto out_err; + pr_warn("failed to add built-in module %s: %d\n", modname, ret); mod_ct++;
[Severity: Low] Similarly, does this unconditional increment of mod_ct inflate the statistics when ddebug_add_module() fails for the final built-in module in dynamic_debug_init()? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260916-dd-cmap-part2-clean-v10-0-af4cf4767707@gmail.com?part=25