lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJfuBxzGKFu9Xd4PhwuBOoEV5uKtrrzeXD9MKLpDAjZL3UqZQw@mail.gmail.com>
Date: Wed, 19 Nov 2025 01:12:08 -0700
From: jim.cromie@...il.com
To: Bagas Sanjaya <bagasdotme@...il.com>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	gregkh@...uxfoundation.org, jbaron@...mai.com, ukaszb@...omium.org, 
	louis.chauvet@...tlin.com
Subject: Re: [PATCH v6 00/31] drm/dyndbg: Fix dynamic debug classmap regression

On Tue, Nov 18, 2025 at 6:35 PM Bagas Sanjaya <bagasdotme@...il.com> wrote:
>
> On Tue, Nov 18, 2025 at 01:18:10PM -0700, Jim Cromie wrote:
> > 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.
>
> What commit/tree this series is based on?
>

this is on top of v6.17
dynamic-debug has been unchanged since then


> Confused...
>
> --
> An old man doll... just what I always wanted! - Clara

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ