Re: [PATCH v11 00/38] dyndbg: Fix classmaps API for subsystems, query extensions, selftests

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 23 Sep 2026 16:34:24 -0600 Jim Cromie <jim.cromie@gmail.com> wrote:

> The drm subsystem has *lots* of debug statements, in 11 categories:
> 
>  $> git grep '\w*_dbg' drivers/gpu/drm/ | wc
>    5663   30159  542864

Methinks this regexp was overly promiscuous, but point taken.

>  $> git grep 'DRM_DEBUG\w*' drivers/gpu/drm/ | wc
>    2206   12834  202332
> 
> All of these are bit-tests on __drm_debug, exposed to users as
> /sys/module/drm/parameters/debug. Many of these are done often;
> vblank is done ~100/sec for some displays. Over the uptime of many
> boxes, this is a lot of cpu cycles on bits that are almost always off.

A __test_bit (or |) every 10ms sounds quite negligible?

Especially if __drm_debug is __read_mostly.  Which it isn't, afaict. 
Um, low-hanging fruit?

> Dynamic-debug excels at replacing such tests with NOOPs (via static
> keys). Classmaps was devised to bring that 0-off-cost to drm's
> categories.
> 
> Classmaps-v1 went into the kernel in Sept 2022, in 2 chunks:
>   b7b4eebdba7b..6ea3bf466ac6    # core dyndbg changes
>   0406faf25fb1..ee7d633f2dfb    # drm adoption
> 
> Sadly DRM-CI found a regression during init with drm.debug=<initval>;
> the static-keys underneath the drm-dbgs in drm.ko got enabled, but
> those in drivers & helpers did not.
> 
> So in Feb 2023, it got pulled:
> commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
> 
> Root Problem:
> 
> DECLARE_DYNDBG_CLASSMAP defined the classmap, but its repeated use in
> both core and drivers violated a K&R rule "define once, refer
> afterwards". This flaw resulted in a regression; with drm.debug=0xFF
> boot arg, drm-core got enabled, but drivers/helpers did not.
> 
> This patchset replaces DECLARE_DYNDBG_CLASSMAP with:
> - DYNAMIC_DEBUG_CLASSMAP_DEFINE (invoked once in the exporting module)
> - DYNAMIC_DEBUG_CLASSMAP_USE (invoked repeatedly in drivers & helpers)
> 
> _DEFINE exports the classmap it creates (in drm.ko), and other modules
> _USE the classmap. The _USE adds a record referencing the _DEFINEd (&
> exported) classmap in a 2nd __dyndbg_class_users section.
> 
> At modprobe, dyndbg scans the new section after __dyndbg_class_maps,
> follows the linkage to the _DEFINEr module, finds the (optional)
> kernel-param controlling the classmap, examines its drm.debug=<initval>,
> and applies it to the module being initialized.
> 
> To recapitulate the multi-module problem wo DRM involvement, we add:
> 
> - tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh:
>   Alters pr_debugs in builtins and test modules,
>   checks results against checksums of expected results
> 
> - lib/test_dynamic_debug.c & test_dynamic_debug_submod.c:
>   Builds parent & _submod modules with _DEFINE and _USE inside #if/#else
>   blocks, reproducing the 2-module scenario under selftests.

So what I'm understanding is that this series presently has no effect
upon DRM?

What subsystems *does* it affect?

Sashiko had quite a bit to say.  It hasn't quite completed at present.
	https://sashiko.dev/#/patchset/20260923-dd-cmap-part2-clean-v11-0-9b6c217fdf2f@gmail.com