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
| ||
|
Date: Fri, 23 Sep 2022 09:29:03 +0200 From: Michal Hocko <mhocko@...e.com> To: Zhongkun He <hezhongkun.hzk@...edance.com> Cc: hannes@...xchg.org, roman.gushchin@...ux.dev, linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, linux-mm@...ck.org, lizefan.x@...edance.com, wuyun.abel@...edance.com Subject: Re: [External] Re: [PATCH] cgroup/cpuset: Add a new isolated mems.policy type. On Wed 14-09-22 23:10:47, Zhongkun He wrote: > > > > > > > Back to the previous question. > > > > > The question is how to implement that with a sensible semantic. > > > > > > > > Thanks for your analysis and suggestions.It is really difficult to add > > > > policy directly to cgroup for the hierarchical enforcement. It > > > > would be a good idea to add pidfd_set_mempolicy. > > > > > > Are you going to pursue that path? > > > Hi Michal, thanks for your suggestion and reply. > > > > > Are you going to pursue that path? > > > > Yes,I'll give it a try as it makes sense to modify the policy dynamically. > > > > Thanks. > > Hi Michal, i have a question about pidfd_set_mempolicy, it would be better > if you have some suggestions. > > The task_struct of processes and threads are independent. If we change the > mempolicy of the process through pidfd_set_mempolicy, the mempolicy of its > thread will not change. Of course users can set the mempolicy of all threads > by iterating through /proc/tgid/task. > > The question is whether we should override the thread's mempolicy when > setting the process's mempolicy. > > There are two options: > A:Change the process's mempolicy and set that mempolicy to all it's threads. > B:Only change the process's mempolicy in kernel. The mempolicy of the thread > needs to be modified by the user through pidfd_set_mempolicy in > userspace, if necessary. set_mempolicy is a per task_struct operation and so should be pidfd based API as well. If somebody requires a per-thread-group setting then the whole group should be iterated. I do not think we have any precendence where pidfd operation on the thread group leader has side effects on other threads as well. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists