linux-kernel - Re: [External] Re: [PATCH] cgroup/cpuset: Add a new isolated mems.policy type.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yy1gP7wcoCqzRa0B@dhcp22.suse.cz>
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