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@xxxxxxxxx/ > > 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
