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 <[email protected]> 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. > 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 [ ... ] > @@ -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? > @@ -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/[email protected]?part=25
