Re: [RFC][PATCH 0/2] Android style loosening of cgroup attach permissions

[Tejun Heo]

Hello, John.

On Tue, Jun 02, 2015 at 12:07:23PM -0700, John Stultz wrote:
> On Wed, May 20, 2015 at 8:41 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> > As a heads up, this is just a first RFC and not a submission.
> >
> > Android currently loosens the cgroup attchment permissions, allowing
> > tasks with CAP_SYS_NICE to be able to allow tasks to move arbitrary
> > tasks across cgroups.
> >
> > At first glance, overloading CAP_SYS_NICE seems a bit hackish, but this
> > shows that there is a active and widely deployed use for different cgroup
> > attachment rules then what is currently available.
> >
> > I've tried to rework the patches so this attachment policy is build
> > time configurable, and wanted to send them out for review so folks
> > might give their thoughts on this implementation and what they might
> > see as a better way to go about achieving the same goal.
> >
> > Thoughts and feedback would be appriciated!
> 
> Ping? Not sure if I hit folks at a busy time or if I didn't cc the right folks?

Can you explain why this is necessary?  android's cgroups usage is
pretty weird at this point.  IIRC, it moves tasks between fg and bg
cgroups with memory immigration turned on which basically forces memcg
to walk every single page relabeling them on each fg/bg switch, which
is a pretty silly thing to do and for this android kernel also removes
a rcu sync operation which makes break things on removal of cgroups,
which android doesn't do.

memcg usage came up a while ago and there wasn't anything major which
can't be achieved (usually better) by following more standard cgroup
usage - changing knobs rather than moving tasks around.

Given that, I'm not sure this patchset makes sense for upstream.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/