On Mon, Apr 19, 2021 at 2:01 AM Peter Zijlstra <pet...@infradead.org> wrote: > > Josh, you being on the other Google team, the one that actually uses the > cgroup interface AFAIU, can you fight the good fight with TJ on this?
A bit of extra context is in https://lore.kernel.org/lkml/cabk29nttscu2ho7v9di+fh2gv8zu5xic5inrwpfclhpd+dk...@mail.gmail.com. On the management/auditing side, the cgroup interface gives a clear indication of which tasks share a cookie. It is a bit less attractive to add a prctl interface for enumerating this. Also on the management side, I illustrated in the above message how a thread would potentially group together other threads. One limitation of the current prctl interface is that the share_{to, from} always operates on the current thread. Granted we can work around this as described, and also potentially extend the prctl interface to operate on two tasks. So I agree that the cgroup interface here isn't strictly necessary, though it seems convenient. I will double-check with internal teams that would be using the interface to see if there are any other considerations I'm missing. On Mon, Apr 19, 2021 at 4:30 AM Tejun Heo <t...@kernel.org> wrote: > > My suggestion is going ahead with the per-process interface with cgroup > extension on mind in case actual use cases arise. Also, when planning cgroup > integration, putting dynamic migration front and center likely isn't a good > idea. tasks would not be frequently moved around; I'd expect security configuration to remain mostly static. Or maybe I'm misunderstanding your emphasis here? If you feel the above is not strong enough (ie. there should be a use case not feasible with prctl), I'd support that we move forward with the prctl stuff for now, since the cgroup interface is independant. Thanks, Josh
