* Re: [PATCH v6 00/31] drm/dyndbg: Fix dynamic debug classmap regression
[not found] ` <5b3d492c-7037-45a5-a001-0064f14d5f81@akamai.com>
@ 2025-12-14 18:24 ` jim.cromie
2025-12-14 19:54 ` Jeff King
0 siblings, 1 reply; 4+ messages in thread
From: jim.cromie @ 2025-12-14 18:24 UTC (permalink / raw)
To: Jason Baron, git; +Cc: linux-kernel, dri-devel, gregkh, ukaszb, louis.chauvet
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 <jbaron@akamai•com> wrote:
>
>
>
> On 12/10/25 4:12 PM, jim.cromie@gmail•com 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 <jbaron@akamai•com> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v6 00/31] drm/dyndbg: Fix dynamic debug classmap regression
2025-12-14 18:24 ` [PATCH v6 00/31] drm/dyndbg: Fix dynamic debug classmap regression jim.cromie
@ 2025-12-14 19:54 ` Jeff King
2025-12-14 22:52 ` jim.cromie
0 siblings, 1 reply; 4+ messages in thread
From: Jeff King @ 2025-12-14 19:54 UTC (permalink / raw)
To: jim.cromie
Cc: Jason Baron, git, linux-kernel, dri-devel, gregkh, ukaszb,
louis.chauvet
On Mon, Dec 15, 2025 at 07:24:34AM +1300, jim.cromie@gmail•com wrote:
> 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
Can you show the exact input you fed to git-am?
Everything applied fine for me using this workflow:
- grab the thread mbox from
https://lore.kernel.org/dri-devel/CAJfuBxzW6TMmdS74ZPfPSe1w6S=oO17WYZc-Jgn_et=-Muw05A@mail.gmail.com/t.mbox.gz
- view that mbox in mutt, tagging all of the 31 messages and then
copying them into their own mbox
- git checkout v6.18 && git am <patches.mbox
-Peff
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v6 00/31] drm/dyndbg: Fix dynamic debug classmap regression
2025-12-14 19:54 ` Jeff King
@ 2025-12-14 22:52 ` jim.cromie
2025-12-15 8:07 ` Jeff King
0 siblings, 1 reply; 4+ messages in thread
From: jim.cromie @ 2025-12-14 22:52 UTC (permalink / raw)
To: Jeff King
Cc: Jason Baron, git, linux-kernel, dri-devel, gregkh, ukaszb,
louis.chauvet
On Mon, Dec 15, 2025 at 8:54 AM Jeff King <peff@peff•net> wrote:
>
> On Mon, Dec 15, 2025 at 07:24:34AM +1300, jim.cromie@gmail•com wrote:
>
> > 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
>
> Can you show the exact input you fed to git-am?
>
in the 1st report, I got mbox.gz from:
https://lore.kernel.org/lkml/20251118201842.1447666-1-jim.cromie@gmail.com/
using the mbox.gz from your link, I get a different failure, this time
on patch 11
jimc@frodo:~/projects/lx/linux.git$ git am --abort
jimc@frodo:~/projects/lx/linux.git$ git describe
v6.18
jimc@frodo:~/projects/lx/linux.git$ cksum
~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz
540358004 206558
/home/jimc/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz
jimc@frodo:~/projects/lx/linux.git$ gunzip
~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz
gzip: /home/jimc/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox
already exists; do you wish to overwrite (y or n)? y
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: docs/dyndbg: explain flags parse 1st
Applying: test-dyndbg: fixup CLASSMAP usage error
Applying: dyndbg: add stub macro for DECLARE_DYNDBG_CLASSMAP
Applying: dyndbg: make ddebug_class_param union members same size
Applying: dyndbg: tweak pr_fmt to avoid expansion conflicts
Applying: dyndbg: refactor param_set_dyndbg_classes and below
Applying: dyndbg: reduce verbose/debug clutter
Applying: dyndbg: drop NUM_TYPE_ARRAY
Applying: dyndbg: hoist classmap-filter-by-modname up to ddebug_add_module
error: patch failed: lib/dynamic_debug.c:170
error: lib/dynamic_debug.c: patch does not apply
Patch failed at 0011 dyndbg: hoist classmap-filter-by-modname up to
ddebug_add_module
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$
Upon closer inspection, it misses several patches, and reorders others ??
in particular, the reported 0011 patch above is numbered 16 in the mbox.
2025-11-18 20:18 ` [PATCH v6 02/31] dyndbg: add stub macro for
DECLARE_DYNDBG_CLASSMAP Jim Cromie
2025-11-18 20:18 ` [PATCH v6 03/31] docs/dyndbg: update examples \012
to \n Jim Cromie
2025-11-20 9:30 ` Bagas Sanjaya
2025-11-18 20:18 ` [PATCH v6 06/31] dyndbg: reword "class unknown," to
"class:_UNKNOWN_" Jim Cromie
2025-11-18 20:18 ` [PATCH v6 09/31] dyndbg: tweak pr_fmt to avoid
expansion conflicts Jim Cromie
2025-11-18 20:18 ` [PATCH v6 12/31] dyndbg: tighten fn-sig of
ddebug_apply_class_bitmap Jim Cromie
2025-11-18 20:18 ` [PATCH v6 13/31] dyndbg: replace classmap list with
a vector Jim Cromie
2025-11-18 20:18 ` [PATCH v6 14/31] dyndbg: macrofy a 2-index for-loop
pattern Jim Cromie
2025-11-18 20:18 ` [PATCH v6 15/31] dyndbg,module: make proper
substructs in _ddebug_info Jim Cromie
2025-11-18 20:18 ` [PATCH v6 16/31] dyndbg: hoist
classmap-filter-by-modname up to ddebug_add_module Jim Cromie
jimc@frodo:~/projects/lx/linux.git$ git --version
git version 2.52.0
Im using fedora packaged git.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v6 00/31] drm/dyndbg: Fix dynamic debug classmap regression
2025-12-14 22:52 ` jim.cromie
@ 2025-12-15 8:07 ` Jeff King
0 siblings, 0 replies; 4+ messages in thread
From: Jeff King @ 2025-12-15 8:07 UTC (permalink / raw)
To: jim.cromie
Cc: Jason Baron, git, linux-kernel, dri-devel, gregkh, ukaszb,
louis.chauvet
On Mon, Dec 15, 2025 at 11:52:38AM +1300, jim.cromie@gmail•com wrote:
> using the mbox.gz from your link, I get a different failure, this time
> on patch 11
> [...]
> jimc@frodo:~/projects/lx/linux.git$ gunzip
> ~/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox.gz
> gzip: /home/jimc/Downloads/PATCH-v6-00-31-drm-dyndbg-Fix-dynamic-debug-classmap-regression.mbox
> already exists; do you wish to overwrite (y or n)? y
> jimc@frodo:~/projects/lx/linux.git$ git am --empty=drop
Ah, that is the difference: you are applying directly from the
downloaded mbox file, whereas I picked out the messages using mutt.
The mbox provided by lore is generally in the order the messages were
received, which does not necessarily correspond to the order they were
sent, or the rfc822 dates, or the subject lines. But "git am" does not
do any sorting; it applies the messages in the order it finds them in
the input mbox. So you get out-of-order patch application.
There's another possible gotcha, as well. The mbox for the thread will
contain other non-patch messages like the cover letter and any review
responses. Adding --empty=drop as you did will generally skip past
those, but not always. If somebody responds and says "Maybe do it like
this" with an inline patch, then "git am" will pick up that patch, too!
It worked for me because when I picked the patches out of the thread in
mutt, it showed them sorted by rfc822 date header and used that same
ordering to dump them to the new, filtered mbox. And of course I
manually decided on which messages were part of the patch series and
excluded the rest (based on subject lines).
It would probably be possible to teach "git am" to sort by date header,
but that's not always right, either (you could have a local series with
out-of-order author dates due to rebasing). You could use the subject
lines as heuristics, if you know that the sender didn't use any exotic
format-patch options. So there are probably some heuristics at play.
And none of those ideas helps with the selection problem, which is
another heuristics ball of wax.
Fortunately, I think b4 has melted that wax for us already (OK, maybe
I'm losing the metaphor). If you do:
b4 mbox https://lore.kernel.org/lkml/20251118201842.1447666-1-jim.cromie@gmail.com/
you'll get that unordered mbox again. But if you use the "am" command:
b4 am https://lore.kernel.org/lkml/20251118201842.1447666-1-jim.cromie@gmail.com/
it figures everything out and gives you the clean series in an mbox. It
also knows how to pick the latest version of the series (your v6 is in
its own thread here, but if it were in a thread with v1..v5, you again
get into another message-selection problem).
-Peff
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-12-15 8:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20251118201842.1447666-1-jim.cromie@gmail.com>
[not found] ` <76038c97-39ca-4672-adc0-4e8fe0e39fc8@akamai.com>
[not found] ` <CAJfuBxxFWD0rEjm-va+Bjmf-m2nfOD_+ZEqKy22WX6QdugQCUw@mail.gmail.com>
[not found] ` <5b3d492c-7037-45a5-a001-0064f14d5f81@akamai.com>
2025-12-14 18:24 ` [PATCH v6 00/31] drm/dyndbg: Fix dynamic debug classmap regression jim.cromie
2025-12-14 19:54 ` Jeff King
2025-12-14 22:52 ` jim.cromie
2025-12-15 8:07 ` Jeff King
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox