hello all,

commit aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro")

added dyndbg's "classmaps" feature, which brought dyndbg's 0-off-cost
debug to DRM.  Dyndbg wired to /sys/module/drm/parameters/debug,
mapped its bits to classes named "DRM_UT_*", and effected the callsite
enablements only on updates to the sys-node (and underlying >control).

Sadly, it hit a CI failure, resulting in:
commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")

The regression was that drivers, when modprobed, did not get the
drm.debug=0xff turn-on action, because that had already been done for
drm.ko itself.

The core design bug is in the DECLARE_DYNDBG_CLASSMAP macro.  Its use
in both drm.ko (ie core) and all drivers.ko meant that they couldn't
fundamentally distinguish their respective roles.  They each
"re-defined" the classmap separately, breaking K&R-101.

My ad-hoc test scripting helped to hide the error from me, by 1st
testing various combos of boot-time module.dyndbg=... and
drm.debug=... configurations, and then inadvertently relying upon
those initializations.

This series addresses both failings:

It replaces DECLARE_DYNDBG_CLASSMAP with

- `DYNAMIC_DEBUG_CLASSMAP_DEFINE`: Used by core modules (e.g.,
  `drm.ko`) to define their classmaps.  Based upon DECLARE, it exports
  the classmap so USE can use it.

- `DYNAMIC_DEBUG_CLASSMAP_USE`: this lets other "subsystem" users
  create a linkage to the classmap defined elsewhere (ie drm.ko).
  These users can then find their "parent" and apply its settings.

It adds a selftest script, and a 2nd "sub-module" to recapitulate
DRM's multi-module "subsystem" use-case, including the specific
failure scenario.

It also adds minor parsing enhancements, allowing easier construction
of multi-part debug configurations.  These enhancements are used to
test classmaps in particular, but are not otherwize required.

Thank you for your review.

P.S. Id also like to "tease" some other work:

1. patchset to send pr_debugs to tracefs on +T flag

   allows 63 "private" tracebufs, 1 "common" one (at 0)
   "drm.debug_2trace=0x1ff" is possible
   from Lukas Bartoski

2. patchset to save 40% of DATA_DATA footprint

   move (modname,filename,function) to struct _ddebug_site
   save their descriptor intervals to 3 maple-trees
   3 accessors fetch on descriptor, from trees
   move __dyndbg_sites __section to INIT_DATA

3. patchset to cache dynamic-prefixes
   should hide 2.s cost increase.


Jim Cromie (31):

fixes, cleanups, simple stuff:

  dyndbg: factor ddebug_match_desc out from ddebug_change
  dyndbg: add stub macro for DECLARE_DYNDBG_CLASSMAP
  docs/dyndbg: update examples \012 to \n
  docs/dyndbg: explain flags parse 1st
  test-dyndbg: fixup CLASSMAP usage error
  dyndbg: reword "class unknown," to "class:_UNKNOWN_"
  dyndbg: make ddebug_class_param union members same size
  dyndbg: drop NUM_TYPE_ARRAY
  dyndbg: tweak pr_fmt to avoid expansion conflicts
  dyndbg: reduce verbose/debug clutter

callchain grooming, re-structs, code simplify/dedup by macros:

  dyndbg: refactor param_set_dyndbg_classes and below
  dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
  dyndbg: replace classmap list with a vector
  dyndbg: macrofy a 2-index for-loop pattern
  dyndbg,module: make proper substructs in _ddebug_info
  dyndbg: hoist classmap-filter-by-modname up to ddebug_add_module
  dyndbg: move mod_name down from struct ddebug_table to _ddebug_info
  dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
  selftests-dyndbg: add a dynamic_debug run_tests target
  dyndbg: change __dynamic_func_call_cls* macros into expressions

core fix, api misuse errors, etc.

  dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP
  dyndbg: detect class_id reservation conflicts
  dyndbg: check DYNAMIC_DEBUG_CLASSMAP_DEFINE args at compile-time
  dyndbg-test: change do_prints testpoint to accept a loopct
  dyndbg-API: promote DYNAMIC_DEBUG_CLASSMAP_PARAM to API
  dyndbg: treat comma as a token separator
  dyndbg: split multi-query strings with %
  selftests-dyndbg: add test_mod_submod
  dyndbg: resolve "protection" of class'd pr_debug
  dyndbg: add DYNAMIC_DEBUG_CLASSMAP_USE_(dd_class_name, offset)
  docs/dyndbg: add classmap info to howto

 .../admin-guide/dynamic-debug-howto.rst       | 179 +++-
 MAINTAINERS                                   |   3 +-
 include/asm-generic/vmlinux.lds.h             |   5 +-
 include/linux/dynamic_debug.h                 | 302 +++++--
 kernel/module/main.c                          |  15 +-
 lib/Kconfig.debug                             |  24 +-
 lib/Makefile                                  |   5 +
 lib/dynamic_debug.c                           | 776 +++++++++++-------
 lib/test_dynamic_debug.c                      | 198 +++--
 lib/test_dynamic_debug_submod.c               |  21 +
 tools/testing/selftests/Makefile              |   1 +
 .../testing/selftests/dynamic_debug/Makefile  |   9 +
 tools/testing/selftests/dynamic_debug/config  |   7 +
 .../dynamic_debug/dyndbg_selftest.sh          | 373 +++++++++
 14 files changed, 1457 insertions(+), 461 deletions(-)
 create mode 100644 lib/test_dynamic_debug_submod.c
 create mode 100644 tools/testing/selftests/dynamic_debug/Makefile
 create mode 100644 tools/testing/selftests/dynamic_debug/config
 create mode 100755 tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh

-- 
2.51.1

On 11/18/25 3:18 PM, Jim Cromie wrote:
> !-------------------------------------------------------------------|
>    This Message Is From an External Sender
>    This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
> hello all,
> 
> commit aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro")
> 
> added dyndbg's "classmaps" feature, which brought dyndbg's 0-off-cost
> debug to DRM.  Dyndbg wired to /sys/module/drm/parameters/debug,
> mapped its bits to classes named "DRM_UT_*", and effected the callsite
> enablements only on updates to the sys-node (and underlying >control).
> 
> Sadly, it hit a CI failure, resulting in:
> commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
> 
> The regression was that drivers, when modprobed, did not get the
> drm.debug=0xff turn-on action, because that had already been done for
> drm.ko itself.
> 
> The core design bug is in the DECLARE_DYNDBG_CLASSMAP macro.  Its use
> in both drm.ko (ie core) and all drivers.ko meant that they couldn't
> fundamentally distinguish their respective roles.  They each
> "re-defined" the classmap separately, breaking K&R-101.
> 
> My ad-hoc test scripting helped to hide the error from me, by 1st
> testing various combos of boot-time module.dyndbg=... and
> drm.debug=... configurations, and then inadvertently relying upon
> those initializations.
> 
> This series addresses both failings:
> 
> It replaces DECLARE_DYNDBG_CLASSMAP with
> 
> - `DYNAMIC_DEBUG_CLASSMAP_DEFINE`: Used by core modules (e.g.,
>    `drm.ko`) to define their classmaps.  Based upon DECLARE, it exports
>    the classmap so USE can use it.
> 
> - `DYNAMIC_DEBUG_CLASSMAP_USE`: this lets other "subsystem" users
>    create a linkage to the classmap defined elsewhere (ie drm.ko).
>    These users can then find their "parent" and apply its settings.
> 
> It adds a selftest script, and a 2nd "sub-module" to recapitulate
> DRM's multi-module "subsystem" use-case, including the specific
> failure scenario.
> 
> It also adds minor parsing enhancements, allowing easier construction
> of multi-part debug configurations.  These enhancements are used to
> test classmaps in particular, but are not otherwize required.
> 
> Thank you for your review.
> 
> P.S. Id also like to "tease" some other work:
> 
> 1. patchset to send pr_debugs to tracefs on +T flag
> 
>     allows 63 "private" tracebufs, 1 "common" one (at 0)
>     "drm.debug_2trace=0x1ff" is possible
>     from Lukas Bartoski
> 
> 2. patchset to save 40% of DATA_DATA footprint
> 
>     move (modname,filename,function) to struct _ddebug_site
>     save their descriptor intervals to 3 maple-trees
>     3 accessors fetch on descriptor, from trees
>     move __dyndbg_sites __section to INIT_DATA
> 
> 3. patchset to cache dynamic-prefixes
>     should hide 2.s cost increase.
> 
> 

Hi Jim,

I just wanted to confirm my understanding that the class names here are 
'global'. That is if say two different modules both used say the name 
"core" in their DYNAMIC_DEBUG_CLASSMAP_DEFINE() name array, then if the 
user did: echo "class core +p > control", then that would enable all the 
sites that had the class name "core" in both modules. One could add the 
"module" modifier to the request if needed.

One could prepend the module name to the class names to make them unique 
but it's not much different from adding a separate 'module blah' in the 
request. So probably fine as is, but maybe worth calling out in the docs 
a bit?

Thanks,

-Jason

On Thu, Dec 11, 2025 at 8:09 AM Jason Baron <jbaron@akamai.com> wrote:
>
>
>
> On 11/18/25 3:18 PM, Jim Cromie wrote:
> > !-------------------------------------------------------------------|
> >    This Message Is From an External Sender
> >    This message came from outside your organization.
> > |-------------------------------------------------------------------!
> >
> > hello all,
> >
> > commit aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro")
> >
> > added dyndbg's "classmaps" feature, which brought dyndbg's 0-off-cost
> > debug to DRM.  Dyndbg wired to /sys/module/drm/parameters/debug,
> > mapped its bits to classes named "DRM_UT_*", and effected the callsite
> > enablements only on updates to the sys-node (and underlying >control).
> >
> > Sadly, it hit a CI failure, resulting in:
> > commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
> >
> > The regression was that drivers, when modprobed, did not get the
> > drm.debug=0xff turn-on action, because that had already been done for
> > drm.ko itself.
> >
> > The core design bug is in the DECLARE_DYNDBG_CLASSMAP macro.  Its use
> > in both drm.ko (ie core) and all drivers.ko meant that they couldn't
> > fundamentally distinguish their respective roles.  They each
> > "re-defined" the classmap separately, breaking K&R-101.
> >
> > My ad-hoc test scripting helped to hide the error from me, by 1st
> > testing various combos of boot-time module.dyndbg=... and
> > drm.debug=... configurations, and then inadvertently relying upon
> > those initializations.
> >
> > This series addresses both failings:
> >
> > It replaces DECLARE_DYNDBG_CLASSMAP with
> >
> > - `DYNAMIC_DEBUG_CLASSMAP_DEFINE`: Used by core modules (e.g.,
> >    `drm.ko`) to define their classmaps.  Based upon DECLARE, it exports
> >    the classmap so USE can use it.
> >
> > - `DYNAMIC_DEBUG_CLASSMAP_USE`: this lets other "subsystem" users
> >    create a linkage to the classmap defined elsewhere (ie drm.ko).
> >    These users can then find their "parent" and apply its settings.
> >
> > It adds a selftest script, and a 2nd "sub-module" to recapitulate
> > DRM's multi-module "subsystem" use-case, including the specific
> > failure scenario.
> >
> > It also adds minor parsing enhancements, allowing easier construction
> > of multi-part debug configurations.  These enhancements are used to
> > test classmaps in particular, but are not otherwize required.
> >
> > Thank you for your review.
> >
> > P.S. Id also like to "tease" some other work:
> >
> > 1. patchset to send pr_debugs to tracefs on +T flag
> >
> >     allows 63 "private" tracebufs, 1 "common" one (at 0)
> >     "drm.debug_2trace=0x1ff" is possible
> >     from Lukas Bartoski
> >
> > 2. patchset to save 40% of DATA_DATA footprint
> >
> >     move (modname,filename,function) to struct _ddebug_site
> >     save their descriptor intervals to 3 maple-trees
> >     3 accessors fetch on descriptor, from trees
> >     move __dyndbg_sites __section to INIT_DATA
> >
> > 3. patchset to cache dynamic-prefixes
> >     should hide 2.s cost increase.
> >
> >
>
> Hi Jim,
>
> I just wanted to confirm my understanding that the class names here are
> 'global'. That is if say two different modules both used say the name
> "core" in their DYNAMIC_DEBUG_CLASSMAP_DEFINE() name array, then if the
> user did: echo "class core +p > control", then that would enable all the
> sites that had the class name "core" in both modules. One could add the
> "module" modifier to the request if needed.
>
> One could prepend the module name to the class names to make them unique
> but it's not much different from adding a separate 'module blah' in the
> request. So probably fine as is, but maybe worth calling out in the docs
> a bit?
>

Yes. that is correct. class CORE is global.
If 2 different DEFINE()s give that classname,
the defining modules will both respond to `class CORE +p > control`
but they will get independent int values (which could be the same, but
dont have to be)

DRM is our case in point.
I reused DRM_UT_CORE...
because I didnt have a good reason to change it
that said, Daniel Vetter noted that the _UT_ part doesnt have a real reason.
So theres some space for a discussion, when I resend that patchset.

`module drm class DRM_UT_CORE +p > control`
will narrow the query and avoid all the drivers/helpers,
which could be what someone wants.
class DRM_UT_CORE would select drivers and helpers too,
so the DRM_UT_  disambiguation is appropriate.

I'll reread the docs to see if theres a bit more I can add to further
explain this.
Do you have any suggestions for wording to achieve this ?

thx,
JIm



> Thanks,
>
> -Jason

On 12/10/25 4:12 PM, jim.cromie@gmail.com wrote:
> !-------------------------------------------------------------------|
>    This Message Is From an External Sender
>    This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
> On Thu, Dec 11, 2025 at 8:09 AM Jason Baron <jbaron@akamai.com> wrote:
>>
>>
>>
>> On 11/18/25 3:18 PM, Jim Cromie wrote:
>>> !-------------------------------------------------------------------|
>>>     This Message Is From an External Sender
>>>     This message came from outside your organization.
>>> |-------------------------------------------------------------------!
>>>
>>> hello all,
>>>
>>> commit aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro")
>>>
>>> added dyndbg's "classmaps" feature, which brought dyndbg's 0-off-cost
>>> debug to DRM.  Dyndbg wired to /sys/module/drm/parameters/debug,
>>> mapped its bits to classes named "DRM_UT_*", and effected the callsite
>>> enablements only on updates to the sys-node (and underlying >control).
>>>
>>> Sadly, it hit a CI failure, resulting in:
>>> commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
>>>
>>> The regression was that drivers, when modprobed, did not get the
>>> drm.debug=0xff turn-on action, because that had already been done for
>>> drm.ko itself.
>>>
>>> The core design bug is in the DECLARE_DYNDBG_CLASSMAP macro.  Its use
>>> in both drm.ko (ie core) and all drivers.ko meant that they couldn't
>>> fundamentally distinguish their respective roles.  They each
>>> "re-defined" the classmap separately, breaking K&R-101.
>>>
>>> My ad-hoc test scripting helped to hide the error from me, by 1st
>>> testing various combos of boot-time module.dyndbg=... and
>>> drm.debug=... configurations, and then inadvertently relying upon
>>> those initializations.
>>>
>>> This series addresses both failings:
>>>
>>> It replaces DECLARE_DYNDBG_CLASSMAP with
>>>
>>> - `DYNAMIC_DEBUG_CLASSMAP_DEFINE`: Used by core modules (e.g.,
>>>     `drm.ko`) to define their classmaps.  Based upon DECLARE, it exports
>>>     the classmap so USE can use it.
>>>
>>> - `DYNAMIC_DEBUG_CLASSMAP_USE`: this lets other "subsystem" users
>>>     create a linkage to the classmap defined elsewhere (ie drm.ko).
>>>     These users can then find their "parent" and apply its settings.
>>>
>>> It adds a selftest script, and a 2nd "sub-module" to recapitulate
>>> DRM's multi-module "subsystem" use-case, including the specific
>>> failure scenario.
>>>
>>> It also adds minor parsing enhancements, allowing easier construction
>>> of multi-part debug configurations.  These enhancements are used to
>>> test classmaps in particular, but are not otherwize required.
>>>
>>> Thank you for your review.
>>>
>>> P.S. Id also like to "tease" some other work:
>>>
>>> 1. patchset to send pr_debugs to tracefs on +T flag
>>>
>>>      allows 63 "private" tracebufs, 1 "common" one (at 0)
>>>      "drm.debug_2trace=0x1ff" is possible
>>>      from Lukas Bartoski
>>>
>>> 2. patchset to save 40% of DATA_DATA footprint
>>>
>>>      move (modname,filename,function) to struct _ddebug_site
>>>      save their descriptor intervals to 3 maple-trees
>>>      3 accessors fetch on descriptor, from trees
>>>      move __dyndbg_sites __section to INIT_DATA
>>>
>>> 3. patchset to cache dynamic-prefixes
>>>      should hide 2.s cost increase.
>>>
>>>
>>
>> Hi Jim,
>>
>> I just wanted to confirm my understanding that the class names here are
>> 'global'. That is if say two different modules both used say the name
>> "core" in their DYNAMIC_DEBUG_CLASSMAP_DEFINE() name array, then if the
>> user did: echo "class core +p > control", then that would enable all the
>> sites that had the class name "core" in both modules. One could add the
>> "module" modifier to the request if needed.
>>
>> One could prepend the module name to the class names to make them unique
>> but it's not much different from adding a separate 'module blah' in the
>> request. So probably fine as is, but maybe worth calling out in the docs
>> a bit?
>>
> 
> Yes. that is correct. class CORE is global.
> If 2 different DEFINE()s give that classname,
> the defining modules will both respond to `class CORE +p > control`
> but they will get independent int values (which could be the same, but
> dont have to be)
> 
> DRM is our case in point.
> I reused DRM_UT_CORE...
> because I didnt have a good reason to change it
> that said, Daniel Vetter noted that the _UT_ part doesnt have a real reason.
> So theres some space for a discussion, when I resend that patchset.
> 
> `module drm class DRM_UT_CORE +p > control`
> will narrow the query and avoid all the drivers/helpers,
> which could be what someone wants.
> class DRM_UT_CORE would select drivers and helpers too,
> so the DRM_UT_  disambiguation is appropriate.
> 
> I'll reread the docs to see if theres a bit more I can add to further
> explain this.
> Do you have any suggestions for wording to achieve this ?
> 


Ok, so sounds like DRM_ prefix is already adding some scoping vs. just 
the simple 'CORE' name. So maybe just something like:

Note that class names exist in a 'global' namespace. Thus, if two 
different modules share a common class name such as 'core' both modules 
will have sites enabled via: echo 'class core +p > control'. Thus, you 
may wish to scope any new class names to a specific use-case or module. 
For example, drm uses the 'DRM_' prefix, as in 'DRM_CORE'.

Thanks,

-Jason

for some reason I cannot grasp,
git am fails to process this mbox.

It entirely misses 13/31,
then fails to apply 14, which needs 13

Im able to cherry-pick 13,
but then I cannot --continue with 14,
even after bumping .git/rebase-apply/next (iirc)

jimc@frodo:~/projects/lx/linux.git$ git am --empty=drop
~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox
Skipping: drm/dyndbg: Fix dynamic debug classmap regression
Applying: dyndbg: factor ddebug_match_desc out from ddebug_change
Applying: dyndbg: add stub macro for DECLARE_DYNDBG_CLASSMAP
Applying: docs/dyndbg: update examples \012 to \n
Applying: test-dyndbg: fixup CLASSMAP usage error
Applying: dyndbg: reword "class unknown," to "class:_UNKNOWN_"
Applying: docs/dyndbg: explain flags parse 1st
Applying: dyndbg: make ddebug_class_param union members same size
Applying: dyndbg: drop NUM_TYPE_ARRAY
Applying: dyndbg: tweak pr_fmt to avoid expansion conflicts
Applying: dyndbg: reduce verbose/debug clutter
Applying: dyndbg: refactor param_set_dyndbg_classes and below
Applying: dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
Applying: dyndbg: macrofy a 2-index for-loop pattern
error: patch failed: lib/dynamic_debug.c:155
error: lib/dynamic_debug.c: patch does not apply
Patch failed at 0014 dyndbg: macrofy a 2-index for-loop pattern
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
jimc@frodo:~/projects/lx/linux.git$ git help am

IOW 1st below fails cuz 2nd was missed.

9d3217b82474 dyndbg: macrofy a 2-index for-loop pattern
0181185c3e75 dyndbg: replace classmap list with a vector
ef6ee2b321ce dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
804e6a0d59b6 dyndbg: refactor param_set_dyndbg_classes and below
039806bc83dd dyndbg: reduce verbose/debug clutter
162a0398fae9 dyndbg: tweak pr_fmt to avoid expansion conflicts
d5524fc1ef31 dyndbg: drop NUM_TYPE_ARRAY
a6e1e7f4da90 dyndbg: make ddebug_class_param union members same size
a1d3e32dd906 dyndbg: reword "class unknown," to "class:_UNKNOWN_"
5692e955f0ce test-dyndbg: fixup CLASSMAP usage error
3ee7e303e78e docs/dyndbg: explain flags parse 1st
2f33390837fb docs/dyndbg: update examples \012 to \n
256317aa5996 dyndbg: add stub macro for DECLARE_DYNDBG_CLASSMAP
37bad039f6c7 dyndbg: factor ddebug_match_desc out from ddebug_change
7d0a66e4bb90 (tag: v6.18, master) Linux 6.18

On Sat, Dec 13, 2025 at 4:57 AM Jason Baron <jbaron@akamai.com> wrote:
>
>
>
> On 12/10/25 4:12 PM, jim.cromie@gmail.com wrote:
> > !-------------------------------------------------------------------|
> >    This Message Is From an External Sender
> >    This message came from outside your organization.
> > |-------------------------------------------------------------------!
> >
> > On Thu, Dec 11, 2025 at 8:09 AM Jason Baron <jbaron@akamai.com> wrote:
> >>
> >>
> >>
> >> On 11/18/25 3:18 PM, Jim Cromie wrote:
> >>> !-------------------------------------------------------------------|
> >>>     This Message Is From an External Sender
> >>>     This message came from outside your organization.
> >>> |-------------------------------------------------------------------!
> >>>
> >>> hello all,
> >>>
> >>> commit aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro")
> >>>
> >>> added dyndbg's "classmaps" feature, which brought dyndbg's 0-off-cost
> >>> debug to DRM.  Dyndbg wired to /sys/module/drm/parameters/debug,
> >>> mapped its bits to classes named "DRM_UT_*", and effected the callsite
> >>> enablements only on updates to the sys-node (and underlying >control).
> >>>
> >>> Sadly, it hit a CI failure, resulting in:
> >>> commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
> >>>
> >>> The regression was that drivers, when modprobed, did not get the
> >>> drm.debug=0xff turn-on action, because that had already been done for
> >>> drm.ko itself.
> >>>
> >>> The core design bug is in the DECLARE_DYNDBG_CLASSMAP macro.  Its use
> >>> in both drm.ko (ie core) and all drivers.ko meant that they couldn't
> >>> fundamentally distinguish their respective roles.  They each
> >>> "re-defined" the classmap separately, breaking K&R-101.
> >>>
> >>> My ad-hoc test scripting helped to hide the error from me, by 1st
> >>> testing various combos of boot-time module.dyndbg=... and
> >>> drm.debug=... configurations, and then inadvertently relying upon
> >>> those initializations.
> >>>
> >>> This series addresses both failings:
> >>>
> >>> It replaces DECLARE_DYNDBG_CLASSMAP with
> >>>
> >>> - `DYNAMIC_DEBUG_CLASSMAP_DEFINE`: Used by core modules (e.g.,
> >>>     `drm.ko`) to define their classmaps.  Based upon DECLARE, it exports
> >>>     the classmap so USE can use it.
> >>>
> >>> - `DYNAMIC_DEBUG_CLASSMAP_USE`: this lets other "subsystem" users
> >>>     create a linkage to the classmap defined elsewhere (ie drm.ko).
> >>>     These users can then find their "parent" and apply its settings.
> >>>
> >>> It adds a selftest script, and a 2nd "sub-module" to recapitulate
> >>> DRM's multi-module "subsystem" use-case, including the specific
> >>> failure scenario.
> >>>
> >>> It also adds minor parsing enhancements, allowing easier construction
> >>> of multi-part debug configurations.  These enhancements are used to
> >>> test classmaps in particular, but are not otherwize required.
> >>>
> >>> Thank you for your review.
> >>>
> >>> P.S. Id also like to "tease" some other work:
> >>>
> >>> 1. patchset to send pr_debugs to tracefs on +T flag
> >>>
> >>>      allows 63 "private" tracebufs, 1 "common" one (at 0)
> >>>      "drm.debug_2trace=0x1ff" is possible
> >>>      from Lukas Bartoski
> >>>
> >>> 2. patchset to save 40% of DATA_DATA footprint
> >>>
> >>>      move (modname,filename,function) to struct _ddebug_site
> >>>      save their descriptor intervals to 3 maple-trees
> >>>      3 accessors fetch on descriptor, from trees
> >>>      move __dyndbg_sites __section to INIT_DATA
> >>>
> >>> 3. patchset to cache dynamic-prefixes
> >>>      should hide 2.s cost increase.
> >>>
> >>>
> >>
> >> Hi Jim,
> >>
> >> I just wanted to confirm my understanding that the class names here are
> >> 'global'. That is if say two different modules both used say the name
> >> "core" in their DYNAMIC_DEBUG_CLASSMAP_DEFINE() name array, then if the
> >> user did: echo "class core +p > control", then that would enable all the
> >> sites that had the class name "core" in both modules. One could add the
> >> "module" modifier to the request if needed.
> >>
> >> One could prepend the module name to the class names to make them unique
> >> but it's not much different from adding a separate 'module blah' in the
> >> request. So probably fine as is, but maybe worth calling out in the docs
> >> a bit?
> >>
> >
> > Yes. that is correct. class CORE is global.
> > If 2 different DEFINE()s give that classname,
> > the defining modules will both respond to `class CORE +p > control`
> > but they will get independent int values (which could be the same, but
> > dont have to be)
> >
> > DRM is our case in point.
> > I reused DRM_UT_CORE...
> > because I didnt have a good reason to change it
> > that said, Daniel Vetter noted that the _UT_ part doesnt have a real reason.
> > So theres some space for a discussion, when I resend that patchset.
> >
> > `module drm class DRM_UT_CORE +p > control`
> > will narrow the query and avoid all the drivers/helpers,
> > which could be what someone wants.
> > class DRM_UT_CORE would select drivers and helpers too,
> > so the DRM_UT_  disambiguation is appropriate.
> >
> > I'll reread the docs to see if theres a bit more I can add to further
> > explain this.
> > Do you have any suggestions for wording to achieve this ?
> >
>
>
> Ok, so sounds like DRM_ prefix is already adding some scoping vs. just
> the simple 'CORE' name. So maybe just something like:
>
> Note that class names exist in a 'global' namespace. Thus, if two
> different modules share a common class name such as 'core' both modules
> will have sites enabled via: echo 'class core +p > control'. Thus, you
> may wish to scope any new class names to a specific use-case or module.
> For example, drm uses the 'DRM_' prefix, as in 'DRM_CORE'.
>
> Thanks,
>
> -Jason

On Mon, Dec 15, 2025 at 07:24:34AM +1300, jim.cromie@gmail.com wrote:

> for some reason I cannot grasp,
> git am fails to process this mbox.
> 
> It entirely misses 13/31,
> then fails to apply 14, which needs 13

Can you show the exact input you fed to git-am?

Everything applied fine for me using this workflow:

  - grab the thread mbox from
    https://lore.kernel.org/dri-devel/CAJfuBxzW6TMmdS74ZPfPSe1w6S=oO17WYZc-Jgn_et=-Muw05A@mail.gmail.com/t.mbox.gz

  - view that mbox in mutt, tagging all of the 31 messages and then
    copying them into their own mbox 

  - git checkout v6.18 && git am <patches.mbox

-Peff

On Mon, Dec 15, 2025 at 8:54 AM Jeff King <peff@peff.net> wrote:
>
> On Mon, Dec 15, 2025 at 07:24:34AM +1300, jim.cromie@gmail.com wrote:
>
> > for some reason I cannot grasp,
> > git am fails to process this mbox.
> >
> > It entirely misses 13/31,
> > then fails to apply 14, which needs 13
>
> Can you show the exact input you fed to git-am?
>

in the 1st report, I got mbox.gz from:
https://lore.kernel.org/lkml/20251118201842.1447666-1-jim.cromie@gmail.com/

using the mbox.gz from your link, I get a different failure, this time
on patch 11


jimc@frodo:~/projects/lx/linux.git$ git am --abort
jimc@frodo:~/projects/lx/linux.git$ git describe
v6.18
jimc@frodo:~/projects/lx/linux.git$  cksum
~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz
540358004 206558
/home/jimc/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz

jimc@frodo:~/projects/lx/linux.git$ gunzip
~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz
gzip: /home/jimc/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox
already exists; do you wish to overwrite (y or n)? y
jimc@frodo:~/projects/lx/linux.git$ git am --empty=drop
~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox
Skipping: drm/dyndbg: Fix dynamic debug classmap regression
Applying: dyndbg: factor ddebug_match_desc out from ddebug_change
Applying: docs/dyndbg: explain flags parse 1st
Applying: test-dyndbg: fixup CLASSMAP usage error
Applying: dyndbg: add stub macro for DECLARE_DYNDBG_CLASSMAP
Applying: dyndbg: make ddebug_class_param union members same size
Applying: dyndbg: tweak pr_fmt to avoid expansion conflicts
Applying: dyndbg: refactor param_set_dyndbg_classes and below
Applying: dyndbg: reduce verbose/debug clutter
Applying: dyndbg: drop NUM_TYPE_ARRAY
Applying: dyndbg: hoist classmap-filter-by-modname up to ddebug_add_module
error: patch failed: lib/dynamic_debug.c:170
error: lib/dynamic_debug.c: patch does not apply
Patch failed at 0011 dyndbg: hoist classmap-filter-by-modname up to
ddebug_add_module
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
jimc@frodo:~/projects/lx/linux.git$

Upon closer inspection, it misses several patches, and reorders others ??

in particular, the reported 0011 patch above is numbered 16 in the mbox.


2025-11-18 20:18 ` [PATCH v6 02/31] dyndbg: add stub macro for
DECLARE_DYNDBG_CLASSMAP Jim Cromie
2025-11-18 20:18 ` [PATCH v6 03/31] docs/dyndbg: update examples \012
to \n Jim Cromie
2025-11-20  9:30   ` Bagas Sanjaya
2025-11-18 20:18 ` [PATCH v6 06/31] dyndbg: reword "class unknown," to
"class:_UNKNOWN_" Jim Cromie
2025-11-18 20:18 ` [PATCH v6 09/31] dyndbg: tweak pr_fmt to avoid
expansion conflicts Jim Cromie
2025-11-18 20:18 ` [PATCH v6 12/31] dyndbg: tighten fn-sig of
ddebug_apply_class_bitmap Jim Cromie
2025-11-18 20:18 ` [PATCH v6 13/31] dyndbg: replace classmap list with
a vector Jim Cromie
2025-11-18 20:18 ` [PATCH v6 14/31] dyndbg: macrofy a 2-index for-loop
pattern Jim Cromie
2025-11-18 20:18 ` [PATCH v6 15/31] dyndbg,module: make proper
substructs in _ddebug_info Jim Cromie

2025-11-18 20:18 ` [PATCH v6 16/31] dyndbg: hoist
classmap-filter-by-modname up to ddebug_add_module Jim Cromie

jimc@frodo:~/projects/lx/linux.git$ git --version
git version 2.52.0
Im using fedora packaged git.

On Mon, Dec 15, 2025 at 11:52:38AM +1300, jim.cromie@gmail.com wrote:

> using the mbox.gz from your link, I get a different failure, this time
> on patch 11
> [...]
> jimc@frodo:~/projects/lx/linux.git$ gunzip
> ~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz
> gzip: /home/jimc/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox
> already exists; do you wish to overwrite (y or n)? y
> jimc@frodo:~/projects/lx/linux.git$ git am --empty=drop

Ah, that is the difference: you are applying directly from the
downloaded mbox file, whereas I picked out the messages using mutt.

The mbox provided by lore is generally in the order the messages were
received, which does not necessarily correspond to the order they were
sent, or the rfc822 dates, or the subject lines. But "git am" does not
do any sorting; it applies the messages in the order it finds them in
the input mbox. So you get out-of-order patch application.

There's another possible gotcha, as well. The mbox for the thread will
contain other non-patch messages like the cover letter and any review
responses. Adding --empty=drop as you did will generally skip past
those, but not always. If somebody responds and says "Maybe do it like
this" with an inline patch, then "git am" will pick up that patch, too!


It worked for me because when I picked the patches out of the thread in
mutt, it showed them sorted by rfc822 date header and used that same
ordering to dump them to the new, filtered mbox. And of course I
manually decided on which messages were part of the patch series and
excluded the rest (based on subject lines).

It would probably be possible to teach "git am" to sort by date header,
but that's not always right, either (you could have a local series with
out-of-order author dates due to rebasing). You could use the subject
lines as heuristics, if you know that the sender didn't use any exotic
format-patch options. So there are probably some heuristics at play.

And none of those ideas helps with the selection problem, which is
another heuristics ball of wax.

Fortunately, I think b4 has melted that wax for us already (OK, maybe
I'm losing the metaphor). If you do:

  b4 mbox https://lore.kernel.org/lkml/20251118201842.1447666-1-jim.cromie@gmail.com/

you'll get that unordered mbox again. But if you use the "am" command:

  b4 am https://lore.kernel.org/lkml/20251118201842.1447666-1-jim.cromie@gmail.com/

it figures everything out and gives you the clean series in an mbox. It
also knows how to pick the latest version of the series (your v6 is in
its own thread here, but if it were in a thread with v1..v5, you again
get into another message-selection problem).

-Peff

On Tue, Nov 18, 2025 at 01:18:10PM -0700, Jim Cromie wrote:
> hello all,
> 
> commit aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro")
> 
> added dyndbg's "classmaps" feature, which brought dyndbg's 0-off-cost
> debug to DRM.  Dyndbg wired to /sys/module/drm/parameters/debug,
> mapped its bits to classes named "DRM_UT_*", and effected the callsite
> enablements only on updates to the sys-node (and underlying >control).
> 
> Sadly, it hit a CI failure, resulting in:
> commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
> 
> The regression was that drivers, when modprobed, did not get the
> drm.debug=0xff turn-on action, because that had already been done for
> drm.ko itself.
> 
> The core design bug is in the DECLARE_DYNDBG_CLASSMAP macro.  Its use
> in both drm.ko (ie core) and all drivers.ko meant that they couldn't
> fundamentally distinguish their respective roles.  They each
> "re-defined" the classmap separately, breaking K&R-101.
> 
> My ad-hoc test scripting helped to hide the error from me, by 1st
> testing various combos of boot-time module.dyndbg=... and
> drm.debug=... configurations, and then inadvertently relying upon
> those initializations.
> 
> This series addresses both failings:
> 
> It replaces DECLARE_DYNDBG_CLASSMAP with
> 
> - `DYNAMIC_DEBUG_CLASSMAP_DEFINE`: Used by core modules (e.g.,
>   `drm.ko`) to define their classmaps.  Based upon DECLARE, it exports
>   the classmap so USE can use it.
> 
> - `DYNAMIC_DEBUG_CLASSMAP_USE`: this lets other "subsystem" users
>   create a linkage to the classmap defined elsewhere (ie drm.ko).
>   These users can then find their "parent" and apply its settings.
> 
> It adds a selftest script, and a 2nd "sub-module" to recapitulate
> DRM's multi-module "subsystem" use-case, including the specific
> failure scenario.
> 
> It also adds minor parsing enhancements, allowing easier construction
> of multi-part debug configurations.  These enhancements are used to
> test classmaps in particular, but are not otherwize required.

What commit/tree this series is based on?

Confused...

-- 
An old man doll... just what I always wanted! - Clara

On Tue, Nov 18, 2025 at 6:35 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>
> On Tue, Nov 18, 2025 at 01:18:10PM -0700, Jim Cromie wrote:
> > hello all,
> >
> > commit aad0214f3026 ("dyndbg: add DECLARE_DYNDBG_CLASSMAP macro")
> >
> > added dyndbg's "classmaps" feature, which brought dyndbg's 0-off-cost
> > debug to DRM.  Dyndbg wired to /sys/module/drm/parameters/debug,
> > mapped its bits to classes named "DRM_UT_*", and effected the callsite
> > enablements only on updates to the sys-node (and underlying >control).
> >
> > Sadly, it hit a CI failure, resulting in:
> > commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
> >
> > The regression was that drivers, when modprobed, did not get the
> > drm.debug=0xff turn-on action, because that had already been done for
> > drm.ko itself.
> >
> > The core design bug is in the DECLARE_DYNDBG_CLASSMAP macro.  Its use
> > in both drm.ko (ie core) and all drivers.ko meant that they couldn't
> > fundamentally distinguish their respective roles.  They each
> > "re-defined" the classmap separately, breaking K&R-101.
> >
> > My ad-hoc test scripting helped to hide the error from me, by 1st
> > testing various combos of boot-time module.dyndbg=... and
> > drm.debug=... configurations, and then inadvertently relying upon
> > those initializations.
> >
> > This series addresses both failings:
> >
> > It replaces DECLARE_DYNDBG_CLASSMAP with
> >
> > - `DYNAMIC_DEBUG_CLASSMAP_DEFINE`: Used by core modules (e.g.,
> >   `drm.ko`) to define their classmaps.  Based upon DECLARE, it exports
> >   the classmap so USE can use it.
> >
> > - `DYNAMIC_DEBUG_CLASSMAP_USE`: this lets other "subsystem" users
> >   create a linkage to the classmap defined elsewhere (ie drm.ko).
> >   These users can then find their "parent" and apply its settings.
> >
> > It adds a selftest script, and a 2nd "sub-module" to recapitulate
> > DRM's multi-module "subsystem" use-case, including the specific
> > failure scenario.
> >
> > It also adds minor parsing enhancements, allowing easier construction
> > of multi-part debug configurations.  These enhancements are used to
> > test classmaps in particular, but are not otherwize required.
>
> What commit/tree this series is based on?
>

this is on top of v6.17
dynamic-debug has been unchanged since then


> Confused...
>
> --
> An old man doll... just what I always wanted! - Clara

On Wed, Nov 19, 2025 at 01:12:08AM -0700, jim.cromie@gmail.com wrote:
> On Tue, Nov 18, 2025 at 6:35 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > What commit/tree this series is based on?
> >
> 
> this is on top of v6.17
> dynamic-debug has been unchanged since then

Pulled for review, thanks!

-- 
An old man doll... just what I always wanted! - Clara