[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180510123541.GO2368884@devbig577.frc2.facebook.com>
Date: Thu, 10 May 2018 05:35:41 -0700
From: Tejun Heo <tj@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Kirill Tkhai <ktkhai@...tuozzo.com>, akpm@...ux-foundation.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>
Subject: Re: [RFC][PATCH] cgroup: Don't mess with tasks in exec
Hello,
On Thu, May 10, 2018 at 02:15:32PM +0200, Oleg Nesterov wrote:
> > So avoid the problems by simply blocking cgroup migration over the
> > entirety of exec.
>
> This patch, even if it was correct, will bring much more problems.
>
> If nothing else exec() is very slow. If it races with migration which needs
> this sem for writing the new readers will be blocked. This means that clone(),
> exit(), or another exec() will block too.
Agreed. I don't think it's a good idea to expand threadgroup coverage
larger than it already is. I'd much prefer either working around the
copy_string case specifically or just ignoring it.
Thanks.
--
tejun
Powered by blists - more mailing lists