linux-kernel - Re: [PATCH 05/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: <0f373a8c-8301-41d9-e042-cfe0cef4bd25@rasmusvillemoes.dk>
Date:   Thu, 28 Nov 2019 09:21:28 +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, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 05/16] dyndbg: fix overcounting of ram used by dyndbg

On 27/11/2019 18.50, Jim Cromie wrote:
> during dyndbg init, verbose logging prints its ram overhead.  It
> counted strlens of struct _ddebug's 4 string members, in all callsite
> entries, which would be approximately correct if each had been
> mallocd.  But they are pointers into shared .rodata; for example, all
> 10 kobject callsites have identical filename, module values.
> 
> Its best not to count that memory at all, since we cannot know they
> were linked in because of CONFIG_DYNAMIC_DEBUG=y, and we want to
> report a number that reflects what ram is saved by deconfiguring it.

That, and we avoid 1000s of (mostly cache-cold) strlen() calls during boot.

Acked-by: Rasmus Villemoes <linux@...musvillemoes.dk>

I'll see if I can find time to review the other patches, then I think
you need to resend with Andrew on the cc-list (added here). I think he's
the one routing lib/dynamic_debug.c patches.

Rasmus