On Thu, Feb 20, 2025 at 1:31 AM Greg KH <[email protected]> wrote: > > 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/[email protected]/ > > > > 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? >
If you'll have it, I'll send you the non-drm parts now. Or the whole thing, and you can take the front half. perhaps its too late for this cycle, but you can send it to linux-next IIUC. This would free Lukas Bartosik to rework his dyndbg-to-tracefs patchset on top. It has the nice feature of private tracefs buffers, allowing to isolate drm.debug messages there. It also enables strong verification in selftests, by ensuring that no unrelated log-msgs get into the private tracebuf. Ive been banging on DRM-CI, with some success. Hopefully enough demonstrated soon to overcome the inertia. https://gitlab.freedesktop.org/jim.cromie/kernel-drm-next-dd.git Some tests on i915 timed out and failed, cuz toggling up to 1800 drm-dbg callsites with dyndbg took 800 ms when 150 ms was expected. I have a fork of IGT adding time-dilation when drm-dbgs with classes are found in dynamic_debug/control. An alternate approach batches 256 static-key toggles in 1 IPI (by sorting rather than flushing on out-of-order addys). This cuts IPIs to 1/170, but is RFC, and only sorted on x86. > And I think the last patch in this series isn't correct, it looks like a > 000 email somehow. > IIRC, that was me trying to get a merge-message or something like it. > thanks, > > greg k-h
