[PATCH 64/64] This series fixes dynamic-debug's support for DRM, aka CONFIG_DRM_USE_DYNAMIC_DEBUG=y

[Jim Cromie]

Despite a few latent flaws, Classmaps-v1 evaded full review, and got
committed in 2 chunks into lib,include and drm:

  b7b4eebdba7b..6ea3bf466ac6	# core dyndbg changes
  0406faf25fb1..ee7d633f2dfb	# drm adoption

Those flaws:

1. Regression during initialization.  classmaps-v1 inits drm-dbg
callsites' static-keys when drm is "modprobed/initd" with
drm.debug=<initval>, but not during driver & helper modprobes.

Previously __drm_debug vs DRM_UT_* was checked at runtime, which made
this a non-issue, but with static-keys set during late initialization,
propagation of classmap to users needed to happen, and didn't.

My test scripts passed dyndbg=<options>, which obscured this lack of
propagation to drivers, and I didn't pick up on it.

2. DECLARE_DYNDBG_CLASSMAP violated a K&R rule "define once, refer
afterwards", and its use in user modules is the root cause under
problem 1.

3. classmaps-v1 was something of a flag-day patchset; dyndbg & DRM
parts were overly coupled, and test-dyndbg didn't anticipate and test
for multi-module classes.

Consequently we got:
commit bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")

Classmaps-v2 fixes these as follows:

2. replace DECLARE_DYNDBG_CLASSMAP with DYNDBG_CLASSMAP_DEFINE
(invoked once in drm-core) and DYNDBG_CLASSMAP_USE (repeatedly, in
drivers & helpers).

_DEFINE now exports the classmap it creates (in drm.ko), other modules
_USE the classmap, since they want to respond to this class's
settings; by either inputs to /sys/module/drm/parameters/debug or
/prod/dynsmic_debug/control.

_USE adds a usage/linkage record referring to the _DEFINEd (&
exported) classmap, in a new __dyndbg_class_users section (in the
using module).  The distinction allows dyndbg to handle the new _USEs
as follows:

1. Now at modprobe, dyndbg scans the new section after the original
__dyndbg_class_maps section, 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.

3. test/validate dyndbg for multi-module classes wo DRM involvement.

A. add test_dynamic_debug_submod.ko, a clone of parent, which _USEs
the parents _DEFINEd classmap.  This allows recapitulating various
multi-module scenarios.

B. add tools/testing/selftests/dynamic_debug/*

test now verifies parsing and effect of applied >controls, including
the multi-module scenarios made possible by 3A.

C. to decouple dyndbg from DRM, DECLARE_DYNDBG_CLASSMAP is preserved
until after DRM adapts to the api change.  Once DRM drops use, I'll
retire it.

Since the last rev sent here/LKML:
  https://lore.kernel.org/lkml/20240716185806.1572048-1-jim.cromie@gmail.com/

Ive rebased onto recent drm-tip, and tested with drm-trybot:
  https://patchwork.freedesktop.org/series/139147/

And made the following additions:

1- drop class "protection" special case, per JBaron's preference.
   current use is marked BROKEN so nobody to affect.
   now framed as policy-choice:
   #define ddebug_client_module_protects_classes() false
   subsystems wanting protection can change this.

2- compile-time arg-tests in DYNDBG_CLASSMAP_DEFINE
   implement several required constraints, and fail obviously.

3- modprobe time check of conflicting class-id reservations
   only affects 2+classmaps users.
   compile-time solution not apparent.

4- dyndbg can now cause modprobe to fail.
   needed to catch 3.
   maybe some loose ends here on failure.

5- refactor & rename ddebug_attach_*module_classes
   reduce repetetive boilerplate on 2 types: maps, users.
   rework mostly brought forward in patchset to reduce churn
   TBD: maybe squash more.

Several recent trybot submissions (against drm-tip) have been passing
CI.BAT, and failing one or few CI.IGT tests randomly; re-tests do not
reliably repeat the failures.

its also at github.com:jimc/linux.git
  dd-fix-9[st]-ontip  &  dd-fix-9-13rc

Ive been running it on my desktop w/o issues.

The drivers/gpu/drm patches are RFC, I think there might be a place to
put a single DRM_CLASSMAP_USE(drm_dedbug_classes) to replace the
sprinkling of _USEs in drivers and helpers.  IIRC, I tried adding a
_DEFINE into drm_drv.c, that didn't do it, so I punted for now.

I think the dyndbg core additions are ready for review and merging
into a (next-next) test/integration tree.

pre-cleanup:
core change:
new features:
finishing:
DRM: (phase 2)
-- 
2.47.1