linux-kernel - Re: Do we still need SLAB_MEM_SPREAD (and possibly others)?

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]

Message-ID: <2efa10b2-6732-4aa5-98ae-34053a5838ee@redhat.com>
Date: Mon, 5 Feb 2024 22:20:57 -0500
From: Waiman Long <longman@...hat.com>
To: "Song, Xiongwei" <Xiongwei.Song@...driver.com>,
 "Christoph Lameter (Ampere)" <cl@...ux.com>,
 Zefan Li <lizefan.x@...edance.com>
Cc: Chengming Zhou <chengming.zhou@...ux.dev>,
 Vlastimil Babka <vbabka@...e.cz>, Yosry Ahmed <yosryahmed@...gle.com>,
 Steven Rostedt <rostedt@...dmis.org>, LKML <linux-kernel@...r.kernel.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Kees Cook <keescook@...omium.org>, David Rientjes <rientjes@...gle.com>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>,
 Chengming Zhou <zhouchengming@...edance.com>,
 Zheng Yejian <zhengyejian1@...wei.com>,
 "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>
Subject: Re: Do we still need SLAB_MEM_SPREAD (and possibly others)?

On 2/5/24 22:16, Waiman Long wrote:
>
> On 2/5/24 20:46, Song, Xiongwei wrote:
>> Adding the maintainers of cpuset of cgroup.
>>
>>> On Sun, 4 Feb 2024, Song, Xiongwei wrote:
>>>
>>>> Once SLAB_MEM_SPREAD is removed, IMO, cpuset.memory_spread_slab is 
>>>> useless.
>>> SLAB_MEM_SPREAD does not do anything anymore. SLUB relies on the
>>> "spreading" via the page allocator memory policies instead of doing its
>>> own like SLAB used to do.
>>>
>>> What does FILE_SPREAD_SLAB do? Dont see anything there either.
>> The FILE_SPREAD_SLAB flag is used by cpuset.memory_spread_slab with 
>> read/write operations:
>>
>> In kernel/cgroup/cpuset.c,
>> static struct cftype legacy_files[] = {
>> ... snip ...
>>          {
>>                  .name = "memory_spread_slab",
>>                  .read_u64 = cpuset_read_u64,
>>                  .write_u64 = cpuset_write_u64,
>>                  .private = FILE_SPREAD_SLAB,
>>          },
>> ... snip ...
>> };
>
> It looks like that memory_spread_slab may have effect only on the slab 
> allocator. With the removal of the slab allocator, memory_spread_slab 
> is now a no-op. However, the memory_spread_slab cgroupfs file is an 
> externally visible API. So we can't just remove it as it may break 
> existing applications. We can certainly deprecate it and advise users 
> not to use it.

BTW, cpuset doesn't use SLAB_MEM_SPREAD directly. Instead it set the 
task's PFA_SPREAD_SLAB and let other subsystems test it to act 
appropriately. Other than cpuset, the latest upstream kernel doesn't 
check or use this flag at all.

Cheers,
Longman