Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Tejun Heo <tj@kernel.org>]

Hello,

On Tue, Jul 19, 2022 at 01:16:02PM -0700, Mina Almasry wrote:
> I think I'm flexible in this sense. Would you like the kernel to
> prevent reattaching the tmpfs to a different cgroup? To be honest we
> have a use case for that, but I'm not going to die on this hill. I
> guess the worst case scenario is that I can carry a local patch on our
> kernel which allows reattaching to a different cgroup and directs
> future charges there...

If it's not gonna be dynamic, putting it in a writable cgroupfs file feels
awakard to me, prone to creating incorrect expectations.

> > I'd much prefer something alont the line of `mount -t tmpfs -o cgroup=XXX`
> > where the tmpfs code checks whether the specified cgroup is one of the
> > ancestors and the mounting task has enough permission to shift the resource
> > there.
> 
> Actually this is pretty much the same interface I opted for in my
> original proposal (except I named it memcg= rather than cgroup=):
> https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

Right. Hmm... the discussion w/ Johannes didn't seem to have concluded, so
continue that here, I guess?

If the consensus becomes that we want to allow charging resources to an
ancestor, I like the the mount option interface a lot more than other
proposals.

> Curious, why do we need to check if the cgroup= is an ancestor? We
> actually do have a use case where the cgroups are unrelated and the
> common ancestor is root. Again, I'm not sure I want to die on this
> hill. At worst I can remove the restriction in a local patch for our
> kernel again...

First of all, permission doesn't capture the whole picture due to delegation
boundaries. Maybe we can use the same perm check as delegation checks but
keeping it inside the subtree seems simpler and less confusing to me. We can
always relax if necessary in the future.

Thanks.

-- 
tejun