On Tue, Nov 18, 2025 at 6:35 PM Bagas Sanjaya <[email protected]> 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

Reply via email to