[PATCH 00/63] Fix CONFIG_DRM_USE_DYNAMIC_DEBUG=y

[Greg KH]

On Fri, Jan 24, 2025 at 11:45:14PM -0700, Jim Cromie wrote:
> This series fixes dynamic-debug's support for DRM debug-categories.
> Classmaps-v1 evaded full review, and got committed in 2 chunks:
> 
>   b7b4eebdba7b..6ea3bf466ac6	# core dyndbg changes
>   0406faf25fb1..ee7d633f2dfb	# drm adoption
> 
> DRM-CI found a regression during init with drm.debug=<initval>; the
> static-keys under the drm-dbgs in drm.ko got enabled, but those in
> drivers & helpers did not.
> 
> Root Problem:
> 
> DECLARE_DYNDBG_CLASSMAP violated a K&R rule "define once, refer
> afterwards".  Replace it with DYNDBG_CLASSMAP_DEFINE (invoked once in
> drm-core) and DYNDBG_CLASSMAP_USE (invoked repeatedly, in drivers &
> helpers).
> 
> _DEFINE exports the classmap it creates (in drm.ko), other modules
> _USE the classmap.  The _USE adds a record ref'g the _DEFINEd (&
> exported) classmap, in a 2nd __dyndbg_class_users section.
> 
> So now at modprobe, dyndbg scans the new section after the 1st
> __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.
> 
> To recapitulate the multi-module problem wo DRM involvement, Add:
> 
> A. tools/testing/selftests/dynamic_debug/*
> 
> This alters pr_debugs in the test-modules, counts the results and
> checks them against expectations.  It uses this formula to test most
> of the control grammar, including the new class keyword.
> 
> B. test_dynamic_debug_submod.ko
> 
> This alters the test-module to build both parent & _submod ko's, with
> _DEFINE and _USE inside #if/#else blocks.  This recap's DRM's 2 module
> failure scenario, allowing A to exersize several cases.
> 
> The #if/#else puts the 2 macro uses together for clarity, and gives
> the 2 modules identical sets of debugs.
> 
> Recent DRM-CI tests are here:
>   https://patchwork.freedesktop.org/series/139147/
> 
> Previous rev:
>   https://lore.kernel.org/lkml/20240716185806.1572048-1-jim.cromie@gmail.com/
> 
> Noteworthy Additions:
> 
> 1- drop class "protection" special case, per JBaron's preference.
>    only 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-13
> 
> Ive been running it on my desktop w/o issues.
> 
> The drivers/gpu/drm patches are RFC, I think there might be a single
> place to call 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.

So whose tree should this go through?

And I think the last patch in this series isn't correct, it looks like a
000 email somehow.

thanks,

greg k-h