linux-kernel - Re: [PATCH 06/16] dyndbg: fix overcounting of ram used by dyndbg

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: <ec6fba26-c384-a29d-eee9-4f0e56c3af06@rasmusvillemoes.dk>
Date:   Tue, 29 Oct 2019 21:47:40 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Jim Cromie <jim.cromie@...il.com>, jbaron@...mai.com,
        linux-kernel@...r.kernel.org
Cc:     greg@...ah.com
Subject: Re: [PATCH 06/16] dyndbg: fix overcounting of ram used by dyndbg

On 29/10/2019 21.00, Jim Cromie wrote:
> during dyndbg init, verbose logging prints its ram overhead.  But it
> counted strlens of all ddebug callsite entries, which are full of
> pointers into shared __dyndbg memory, and shouldnt be counted at all
> (since theyre already in the __dyndbg section)

Hm. I agree we're probably overcounting, but the strings themselves do
not live in __dyndbg, but in .rodata. It's true that __FILE__ (and maybe
in a few cases ->format) get's deduplicated and by the nature of
__func__, ->function points at a unique-per-function string.

So I think the commit log is a bit misleading. However, I think the
patch is a good idea anyway: avoiding 4N strlen() calls during boot is a
good thing. And if anybody wants to know how much memory is used by the
pointed-to-strings, well, "wc dynamic_debug/control" should give an idea.

Rasmus