Re: [PATCH v10 14/38] dyndbg: Bind callsites and classmaps to DDEBUG_MODNAME

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dyndbg: overriding DDEBUG_MODNAME breaks loadable module classmaps
--

commit c306ec85ef6e2f768827879da6cc3ed714ab0291
Author: Jim Cromie <jim.cromie@gmail.com>
dyndbg: Bind callsites and classmaps to DDEBUG_MODNAME

This commit defines DDEBUG_MODNAME to allow subsystems to consolidate their
module names in dynamic debug by overriding it in their Makefiles. It binds
DDEBUG_MODNAME into the callsite and classmap declarator macros instead of
hardcoding KBUILD_MODNAME.

> diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
> index baf5c0853f459..85863e24ad134 100644
> --- a/include/linux/dynamic_debug.h
> +++ b/include/linux/dynamic_debug.h
[ ... ]
> @@ -121,7 +129,7 @@ struct ddebug_class_param {
>  	static struct ddebug_class_map __aligned(8) __used		\
>  		__section("__dyndbg_classes") _var = {			\
>  		.mod = THIS_MODULE,					\
> -		.mod_name = KBUILD_MODNAME,				\
> +		.mod_name = DDEBUG_MODNAME,				\

[Severity: Medium]
Will this break loadable module classmaps if a subsystem opts into the
DDEBUG_MODNAME override?

When a module is loaded, the module loader assigns the physical module name
from the .ko filename to dt->mod_name in ddebug_module_notify(). However,
this macro embeds the overridden DDEBUG_MODNAME into cm->mod_name.

In lib/dynamic_debug.c:ddebug_attach_module_classes(), there is a strict
comparison between these two names:

    if (!strcmp(cm->mod_name, dt->mod_name)) {

If the DDEBUG_MODNAME differs from the physical module name, won't the
classmaps be silently discarded for loadable modules?

Also, won't queries against the consolidated module name fail because
ddebug_change() filters using the physical module name?

lib/dynamic_debug.c:ddebug_change() {
    ...
    if (query->module &&
        !match_wildcard(query->module, dt->mod_name))
            continue;
    ...
}

Subsequent patches in the series, such as the one introducing
dd_set_module_subrange(), appear to preserve this logic.

>  		.base = _base,						\
>  		.map_type = _maptype,					\
>  		.class_names = _var##_classnames,			\

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