Re: [PATCH v7 26/29] dyndbg: move mod_name down from struct ddebug_table to _ddebug_info

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] When processing a built-in module that has no class maps, `ddebug_attach_module_classes()` fails to reset `dt->info.maps.len` to 0, causing the module to erroneously inherit the global array of all built-in class maps.
--

--- Patch [26]: [PATCH v7 26/29] dyndbg: move mod_name down from struct ddebug_table to _ddebug_info ---
commit bd18115a5b87d80ee2f5c15c166c46a301cbd184
Author: Jim Cromie <[email protected]>

    dyndbg: move mod_name down from struct ddebug_table to _ddebug_info
    
    struct _ddebug_info already has most of dyndbg's info for a module;
    push debug_table.mod_name down into it, finishing the encapsulation.

This commit moves the module name from struct ddebug_table into
struct _ddebug_info. This encapsulates the module information, allowing
several callchains to pass _ddebug_info directly rather than the full table.

> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index e7742fcca50ba..905277fa495b4 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
[ ... ]
> @@ -1187,7 +1187,7 @@ static void ddebug_attach_module_classes(struct ddebug_table *dt, struct _ddebug
>  	 * and length of the subrange at its edges.
>  	 */
>  	for_subvec(i, cm, di, maps) {
> -		if (!strcmp(cm->mod_name, dt->mod_name)) {
> +		if (!strcmp(cm->mod_name, dt->info.mod_name)) {
>  			if (!nc) {
>  				v2pr_info("start subrange, class[%d]: module:%s base:%d len:%d ty:%d\n",
>  					  i, cm->mod_name, cm->base, cm->length, cm->map_type);
> @@ -1201,7 +1201,7 @@ static void ddebug_attach_module_classes(struct ddebug_table *dt, struct _ddebug
>  	}
>  	if (nc) {
>  		dt->info.maps.len = nc;
> -		vpr_info("module:%s attached %d classes\n", dt->mod_name, nc);
> +		vpr_info("module:%s attached %d classes\n", dt->info.mod_name, nc);
>  	}
>  }

[Severity: Medium]
When processing a built-in module that has no class maps, does
ddebug_attach_module_classes() fail to reset dt->info.maps.len to 0?

During boot, dynamic_debug_init() creates a stack variable di where maps.start
and maps.len cover the entire __dyndbg_class_maps section. For each built-in
module, ddebug_add_module(&di) is called. It performs a shallow copy
dt->info = *di, assigning the full length.

It then calls ddebug_attach_module_classes(). If the module has no class maps,
the loop finds no matches (nc == 0), skipping the if (nc) block:

	if (nc) {
		dt->info.maps.len = nc;
		vpr_info("module:%s attached %d classes\n", dt->info.mod_name, nc);
	}

Because of this, does dt->info.maps.len improperly retain the length of all
built-in class maps, causing the module to erroneously inherit the global array
of all built-in class maps?

This logic error could allow users to apply unrelated class strings to a
module's debug prints via the control interface, leading to incorrect functional
behavior of the dynamic debug API.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=26