linux-kernel - Re: [RFC][PATCH 1/2] memcg: Ensure every task that uses an mm is in the same memory cgroup

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:   Mon, 04 Jun 2018 14:11:11 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Tejun Heo <tj@...nel.org>
Cc:     Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>, peterz@...radead.org,
        viro@...iv.linux.org.uk, mingo@...nel.org,
        paulmck@...ux.vnet.ibm.com, keescook@...omium.org, riel@...hat.com,
        tglx@...utronix.de, kirill.shutemov@...ux.intel.com,
        marcos.souza.org@...il.com, hoeun.ryu@...il.com,
        pasha.tatashin@...cle.com, gs051095@...il.com, dhowells@...hat.com,
        rppt@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
        Balbir Singh <balbir@...ux.vnet.ibm.com>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: [RFC][PATCH 1/2] memcg: Ensure every task that uses an mm is in the same memory cgroup

Tejun Heo <tj@...nel.org> writes:

> Hello, Michal.
>
> On Mon, Jun 04, 2018 at 03:01:19PM +0200, Michal Hocko wrote:
>> > On Fri, Jun 01, 2018 at 01:11:59PM -0500, Eric W. Biederman wrote:
>> > > Widening the definition of a process sounds good.  The memory control
>> > > group code would still need a way to forbid these in cgroup v1 mode,
>> > > when someone uses the task file.
>> > 
>> > Yeap, you're right.  We'll need memcg's can_attach rejecting for v1.
>> 
>> Do we really need? I mean, do we know about any existing usecase that
>> would need this weird threading concept and depend on memory migration
>> which doesn't really work?
>
> I thought the requirement is from the ->owner change so that the
> association doesn't become 1:N, right?

Yes.  We need not the existing can_attach, but my new
mem_cgroup_mm_can_attach.

Even if the cgroup notion of a process is extended to be any set of
tasks that shares an mm.  We still need to fail cgroup migration through
the tasks file for processes that are not single threaded for cgroup v1.

Eric