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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aR0e0rgrdXWIo8nI@archie.me>
Date: Wed, 19 Nov 2025 08:35:14 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Jim Cromie <jim.cromie@...il.com>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, gregkh@...uxfoundation.org,
	jbaron@...mai.com
Cc: 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 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?

Confused...

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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ