linux-kernel - Re: [PATCH v9 30/52] drm-dyndbg: adapt drm core to use dyndbg classmaps-v2

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJfuBxx1wz=bMOyfiRRhrGyZTqnqZsUmi9Vubs23Yi1px9sZ-g@mail.gmail.com>
Date: Tue, 9 Jul 2024 18:25:19 -0600
From: jim.cromie@...il.com
To: Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc: daniel.vetter@...ll.ch, tvrtko.ursulin@...ux.intel.com, 
	jani.nikula@...el.com, jbaron@...mai.com, gregkh@...uxfoundation.org, 
	ukaszb@...omium.org, linux-kernel@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org, 
	intel-gvt-dev@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org, 
	linux@...musvillemoes.dk, joe@...ches.com, mcgrof@...nel.org
Subject: Re: [PATCH v9 30/52] drm-dyndbg: adapt drm core to use dyndbg classmaps-v2

On Wed, Jul 3, 2024 at 10:11 AM <jim.cromie@...il.com> wrote:
>
> Got it.
> I had some mental block about passing designated intializers as macro args.
> it just worked, I needed to eyeball the .i file just to be sure.
> thanks.
> I have a fixup patch.
> whats the best thing to do with it, squash it in for later ? send in
> reply here ?
>

I have to retract on designated-initializers into DYNDBG_CLASSMAP_DEFINE

While it works for DRM, and looks good, and self-documenting,
it only works cuz DRM_UT_CORE = 0,
and breaks when I used it 2x in test-dynamic-debug.ko.
the 2nd _DEFINE needs a _base > DRM_UT_LAST.


With designated-init exprs passed in thru the macro, I get:

    1st classmap below is bad - the length should be 8, but is 28 cuz
init started at 20.

    (gdb) p *di->classes@di->num_classes
    $2 = {{mod = 0xffffffffc0203740, mod_name = 0xffffffffc0206220
"test_dynamic_debug",
        class_names = 0xffffffffc0203080, length = 28, base = 20,
map_type = DD_CLASS_TYPE_LEVEL_NUM}, {
        mod = 0xffffffffc0203740, mod_name = 0xffffffffc0206220
"test_dynamic_debug",
        class_names = 0xffffffffc0203160, length = 10, base = 0,
map_type = DD_CLASS_TYPE_DISJOINT_BITS}}
    (gdb)

    so 1st 20 classnames are empty, and classnames -> index -> classid
translation fails later.

    (gdb) p *di->classes[0]->class_names@di->classes[0]->length
    $4 = {0x0 <fixed_percpu_data> <repeats 20 times>,
0xffffffffc0206356 "V0", 0xffffffffc0206359 "V1",
      0xffffffffc020635c "V2", 0xffffffffc020635f "V3",
0xffffffffc0206362 "V4", 0xffffffffc0206365 "V5",
      0xffffffffc0206368 "V6", 0xffffffffc020636b "V7"}
    (gdb)

Basically, when designated-inits are passed in, the _base param is redundant,
and the once guaranteed contiguous 0-based classnames list is now
guaranteed sparse.

the macro could be altered to expect designated-inits,
but I couldnt distinguish between the 2 different uses,
so theres a mis-use potential either way.

Id prefer to keep the _DEFINE the way it is,
and better kdoc & howto this to explain away the potential.

BTW: Im aware I failed to delete some v9*patch files before git send-email,
Im considering my penance, will resend soon.