Re: [PATCH v8 29/43] dyndbg: detect class_id reservation conflicts
From: sashiko-bot@kernel.org
Date: 2026-09-05 18:30:58
Also in:
dri-devel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] A classmap conflict in a single built-in module causes dynamic_debug_init() to fail, completely disabling dynamic debugging system-wide. -- commit 10601ffba9f53c0ad961efc6f72432bdf809f6d1 Author: Jim Cromie [off-list ref] dyndbg: detect class_id reservation conflicts This commit detects if a module defines multiple classmaps that overlap in the 0..62 class-id space. It adds overlap checking in ddebug_add_module() and returns -EINVAL when conflicts are detected, ensuring that class_id to classname lookup works properly.
quoted hunk ↗ jump to hunk
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index ba618dcf9677f..0f89b6784ab26 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -1409,16 +1425,24 @@ static int ddebug_add_module(struct _ddebug_info *di) dd_set_module_subrange(i, cm, &dt->info, maps); dd_set_module_subrange(i, cli, &dt->info, users); + /* insure 2+ classmaps share the per-module 0..62 class_id space */ + for_subvec(i, cm, &dt->info, maps) + if (ddebug_class_range_overlap(cm, &reserved_ids)) + goto cleanup; + mutex_lock(&ddebug_lock); list_add_tail(&dt->link, &ddebug_tables); mutex_unlock(&ddebug_lock); - if (dt->info.users.len) ddebug_apply_class_users(&dt->info); vpr_info("%3u debug prints in module %s\n", dt->info.descs.len, dt->info.mod_name); return 0; +cleanup: + WARN_ONCE(1, "dyndbg multi-classmap conflict in %s\n", di->mod_name); + kfree(dt); + return -EINVAL; }
[Severity: High]
Does returning an error here cause a systemic failure for built-in modules?
Looking at dynamic_debug_init(), it iterates over all built-in modules
and calls ddebug_add_module() for each one. If any single module fails,
it aborts initialization:
lib/dynamic_debug.c:dynamic_debug_init() {
...
if (strcmp(modname, iter->modname)) {
...
ret = ddebug_add_module(&di);
if (ret)
goto out_err;
...
out_err:
ddebug_remove_all_tables();
return 0;
}
If a single built-in module has an overlapping classmap, the new -EINVAL return
bubbles up and triggers the out_err path. This destroys all previously loaded
tables and completely disables dynamic debugging system-wide, rather than just
skipping the misconfigured module. Should ddebug_add_module() failure be
non-fatal for built-in modules, or perhaps handled more gracefully?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260905-dd-cmap-part2-clean-v8-0-a4cc0674f6fd@gmail.com?part=29