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

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:   Wed, 13 Jan 2021 19:11:55 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Christoph Lameter <cl@...ux.com>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Pekka Enberg <penberg@...nel.org>
Subject: Re: [PATCH] mm/slub: disable user tracing for kmemleak caches

On Wed, 2021-01-13 at 17:59 +0100, Vlastimil Babka wrote:
> On 1/13/21 5:09 PM, 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>
> 
> How about stripping away SLAB_STORE_USER only if it's added from the global
> slub_debug variable? In case somebody lists one of the kmemleak caches
> explicitly in "slub_debug=..." instead of just booting with "slub_debug", we
> should honor that.

Good point, that makes a lot of sense.

TBH, I mostly sent this to see if anyone would think it acceptable. I've
now disabled slub debugging completely for the kmemleak caches by
command line, and as expected that improves things further. I'm _hoping_
of course that kmemleak itself doesn't contain egregious bugs, but seems
like a fair bet for now :)

So what do you/people think? Should we disable this? Disable all?
Subject to the above constraint, either way.

Thanks,
johannes