linux-kernel - Re: [PATCH v2] mm/slub: disable user tracing for kmemleak caches by default

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]

Date:   Thu, 14 Jan 2021 11:13:06 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Johannes Berg <johannes.berg@...el.com>
Subject: Re: [PATCH v2] mm/slub: disable user tracing for kmemleak caches by
 default

On Wed, Jan 13, 2021 at 09:51:14PM +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@...el.com>
> 
> If kmemleak is enabled, it uses a kmem cache for its own objects.
> These objects are used to hold information kmemleak uses, including
> a stack trace. If slub_debug is also turned on, each of them has
> *another* stack trace, so the overhead adds up, and on my tests (on
> ARCH=um, admittedly) 2/3rds of the allocations end up being doing
> the stack tracing.
> 
> Turn off SLAB_STORE_USER if SLAB_NOLEAKTRACE was given, to avoid
> storing the essentially same data twice.
> 
> Signed-off-by: Johannes Berg <johannes.berg@...el.com>

I think that's the simplest.

Acked-by: Catalin Marinas <catalin.marinas@....com>

> Perhaps instead it should go the other way around, and kmemleak
> could even use/access the stack trace that's already in there ...
> But I don't really care too much, I can just turn off slub debug
> for the kmemleak caches via the command line anyway :-)

This stack trace doesn't seem to be accessible in a unified way across
the sl*b allocators. Given that kmemleak already needs to track this
information for other objects (vmalloc, certain page allocations), it's
probably more hassle to handle it differently for slab objects (I don't
say it's impossible, just not sure it's worth).

-- 
Catalin