linux-kernel - Re: [PATCH 04/16] dyndbg: rename __verbose section to _

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]

Date:   Tue, 29 Oct 2019 15:25:33 -0600
From:   jim.cromie@...il.com
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Jason Baron <jbaron@...mai.com>,
        LKML <linux-kernel@...r.kernel.org>, Greg KH <greg@...ah.com>,
        Arnd Bergmann <arnd@...db.de>, Jessica Yu <jeyu@...nel.org>,
        linux-arch@...r.kernel.org
Subject: Re: [PATCH 04/16] dyndbg: rename __verbose section to __dyndbg

On Tue, Oct 29, 2019 at 2:37 PM Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
>
> On 29/10/2019 21.00, Jim Cromie wrote:
> > dyndbg populates its callsite info into __verbose section, change that
> > to a more specific and descriptive name, __dyndbg.
>
> Yeah, that has always bugged me. Ack to that part.
>
> > Also, per checkpatch:
> >   move extern struct _ddebug __(start|stop)__dyndbg[] to header file
>
> Hm, why? checkpatch should often be ignored. Since we only refer to
> those symbols in the .c file, there's no reason to pollute every other
> translation unit with those declarations. Having declarations in a
> header makes sense when the actual entity gets defined in some .c file
> (which hopefully also includes the header). But these are defined by the
> linker, so there's no type safety to be had.
>

checkpatch wasnt in a mood to explain itself,
but the other simplification seemed good, credit by association

I guess the action-at-a-distance feel to the linker magic
and the extern qualifier, swung me toward heeding the advice.
OTOH, as you note, only dyndbg should be mucking with the symbols.



> >   simplify __attribute(..) to __section(__dyndbg) declaration.
>
> Makes sense, since you're munching the thing anyway.
>
> Rasmus