for some reason I cannot grasp, git am fails to process this mbox. It entirely misses 13/31, then fails to apply 14, which needs 13
Im able to cherry-pick 13, but then I cannot --continue with 14, even after bumping .git/rebase-apply/next (iirc) jimc@frodo:~/projects/lx/linux.git$ git am --empty=drop ~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox Skipping: drm/dyndbg: Fix dynamic debug classmap regression Applying: dyndbg: factor ddebug_match_desc out from ddebug_change Applying: dyndbg: add stub macro for DECLARE_DYNDBG_CLASSMAP Applying: docs/dyndbg: update examples \012 to \n Applying: test-dyndbg: fixup CLASSMAP usage error Applying: dyndbg: reword "class unknown," to "class:_UNKNOWN_" Applying: docs/dyndbg: explain flags parse 1st Applying: dyndbg: make ddebug_class_param union members same size Applying: dyndbg: drop NUM_TYPE_ARRAY Applying: dyndbg: tweak pr_fmt to avoid expansion conflicts Applying: dyndbg: reduce verbose/debug clutter Applying: dyndbg: refactor param_set_dyndbg_classes and below Applying: dyndbg: tighten fn-sig of ddebug_apply_class_bitmap Applying: dyndbg: macrofy a 2-index for-loop pattern error: patch failed: lib/dynamic_debug.c:155 error: lib/dynamic_debug.c: patch does not apply Patch failed at 0014 dyndbg: macrofy a 2-index for-loop pattern hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config set advice.mergeConflict false" jimc@frodo:~/projects/lx/linux.git$ git help am IOW 1st below fails cuz 2nd was missed. 9d3217b82474 dyndbg: macrofy a 2-index for-loop pattern 0181185c3e75 dyndbg: replace classmap list with a vector ef6ee2b321ce dyndbg: tighten fn-sig of ddebug_apply_class_bitmap 804e6a0d59b6 dyndbg: refactor param_set_dyndbg_classes and below 039806bc83dd dyndbg: reduce verbose/debug clutter 162a0398fae9 dyndbg: tweak pr_fmt to avoid expansion conflicts d5524fc1ef31 dyndbg: drop NUM_TYPE_ARRAY a6e1e7f4da90 dyndbg: make ddebug_class_param union members same size a1d3e32dd906 dyndbg: reword "class unknown," to "class:_UNKNOWN_" 5692e955f0ce test-dyndbg: fixup CLASSMAP usage error 3ee7e303e78e docs/dyndbg: explain flags parse 1st 2f33390837fb docs/dyndbg: update examples \012 to \n 256317aa5996 dyndbg: add stub macro for DECLARE_DYNDBG_CLASSMAP 37bad039f6c7 dyndbg: factor ddebug_match_desc out from ddebug_change 7d0a66e4bb90 (tag: v6.18, master) Linux 6.18 On Sat, Dec 13, 2025 at 4:57 AM Jason Baron <[email protected]> wrote: > > > > On 12/10/25 4:12 PM, [email protected] wrote: > > !-------------------------------------------------------------------| > > This Message Is From an External Sender > > This message came from outside your organization. > > |-------------------------------------------------------------------! > > > > On Thu, Dec 11, 2025 at 8:09 AM Jason Baron <[email protected]> wrote: > >> > >> > >> > >> On 11/18/25 3:18 PM, Jim Cromie wrote: > >>> !-------------------------------------------------------------------| > >>> This Message Is From an External Sender > >>> This message came from outside your organization. > >>> |-------------------------------------------------------------------! > >>> > >>> 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. > >>> > >>> Thank you for your review. > >>> > >>> P.S. Id also like to "tease" some other work: > >>> > >>> 1. patchset to send pr_debugs to tracefs on +T flag > >>> > >>> allows 63 "private" tracebufs, 1 "common" one (at 0) > >>> "drm.debug_2trace=0x1ff" is possible > >>> from Lukas Bartoski > >>> > >>> 2. patchset to save 40% of DATA_DATA footprint > >>> > >>> move (modname,filename,function) to struct _ddebug_site > >>> save their descriptor intervals to 3 maple-trees > >>> 3 accessors fetch on descriptor, from trees > >>> move __dyndbg_sites __section to INIT_DATA > >>> > >>> 3. patchset to cache dynamic-prefixes > >>> should hide 2.s cost increase. > >>> > >>> > >> > >> Hi Jim, > >> > >> I just wanted to confirm my understanding that the class names here are > >> 'global'. That is if say two different modules both used say the name > >> "core" in their DYNAMIC_DEBUG_CLASSMAP_DEFINE() name array, then if the > >> user did: echo "class core +p > control", then that would enable all the > >> sites that had the class name "core" in both modules. One could add the > >> "module" modifier to the request if needed. > >> > >> One could prepend the module name to the class names to make them unique > >> but it's not much different from adding a separate 'module blah' in the > >> request. So probably fine as is, but maybe worth calling out in the docs > >> a bit? > >> > > > > Yes. that is correct. class CORE is global. > > If 2 different DEFINE()s give that classname, > > the defining modules will both respond to `class CORE +p > control` > > but they will get independent int values (which could be the same, but > > dont have to be) > > > > DRM is our case in point. > > I reused DRM_UT_CORE... > > because I didnt have a good reason to change it > > that said, Daniel Vetter noted that the _UT_ part doesnt have a real reason. > > So theres some space for a discussion, when I resend that patchset. > > > > `module drm class DRM_UT_CORE +p > control` > > will narrow the query and avoid all the drivers/helpers, > > which could be what someone wants. > > class DRM_UT_CORE would select drivers and helpers too, > > so the DRM_UT_ disambiguation is appropriate. > > > > I'll reread the docs to see if theres a bit more I can add to further > > explain this. > > Do you have any suggestions for wording to achieve this ? > > > > > Ok, so sounds like DRM_ prefix is already adding some scoping vs. just > the simple 'CORE' name. So maybe just something like: > > Note that class names exist in a 'global' namespace. Thus, if two > different modules share a common class name such as 'core' both modules > will have sites enabled via: echo 'class core +p > control'. Thus, you > may wish to scope any new class names to a specific use-case or module. > For example, drm uses the 'DRM_' prefix, as in 'DRM_CORE'. > > Thanks, > > -Jason
