linux-kernel - Re: [PATCH] mm/slab: add new flag SLAB_NO

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:   Wed, 24 May 2023 15:53:11 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Hyeonggon Yoo <42.hyeyoo@...il.com>,
        David Sterba <dsterba@...e.com>
Cc:     Christoph Lameter <cl@...ux.com>,
        David Rientjes <rientjes@...gle.com>,
        Pekka Enberg <penberg@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Roman Gushchin <roman.gushchin@...ux.dev>
Subject: Re: [PATCH] mm/slab: add new flag SLAB_NO_MERGE to avoid merging per
 slab

On 5/24/23 14:56, Hyeonggon Yoo wrote:
> On Wed, May 24, 2023 at 12:17:48PM +0200, David Sterba wrote:
>> Add a flag that allows to disable merging per slab. This can be used for
>> more fine grained control over the caches or for debugging builds where
>> separate slabs can verify that no objects leak.
>> The slab_nomerge boot option is too coarse and would need to be enabled
>> on all testing hosts. 
> 
> Hello David,
> 
> There is no users nor interface to set this flag, I guess you're going
> to use it by modifying source code, when debugging?
> 
> Does introducing new slub_debug option (i.e. slub_debug=N,pid_namespace)
> work for your use case? (there are some boot-time slub_debug options described in
> Documentation/mm/slub.rst)

Yeah, it supports globbing so it would be e.g. slub_debug=N,btrfs*
That would deal with the "too coarse" aspect slab_nomerge. As for "need to
be enabled on all testing hosts", is it more convenient to deploy a debug
kernel build on them? Might be because you do that for other reasons
already? Just want to clarify.

BTW this was proposed as RFC few months ago but not pursued:
https://lore.kernel.org/all/167396280045.539803.7540459812377220500.stgit@firesoul/

I have no big objections, just wouldn't like to see its usage proliferate
unconditionally into non-debug builds.

>> There are some other ways how to disable merging,
>> e.g. a slab constructor but this disables poisoning besides that it adds
>> additional overhead. Other flags are internal and may have other
>> semantics.
>>
>> A concrete example what motivates the flag. During 'btrfs balance' slab
>> top reported huge increase in caches like
>> 
>>   1330095 1330095 100%    0.10K  34105       39    136420K Acpi-ParseExt
>>   1734684 1734684 100%    0.14K  61953       28    247812K pid_namespace
>>   8244036 6873075  83%    0.11K 229001       36    916004K khugepaged_mm_slot
>> 
>> which was confusing and that it's because of slab merging was not the
>> first idea.  After rebooting with slab_nomerge all the caches were from
>> btrfs_ namespace as expected.
>>
>> Signed-off-by: David Sterba <dsterba@...e.com>
>> ---
>>  include/linux/slab.h | 3 +++
>>  mm/slab_common.c     | 2 +-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>> 
>> diff --git a/include/linux/slab.h b/include/linux/slab.h
> 
> Thanks,
>