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: <da2417c0-49f1-4674-95f9-297d6cd9e0fa@redhat.com>
Date: Mon, 5 Feb 2024 22:16:39 -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 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.

Cheers,
Longman



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ