BPF List
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	 Martin KaFai Lau <martin.lau@linux.dev>,
	KP Singh <kpsingh@kernel.org>,
	bpf@vger.kernel.org,  linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org,
	 Lennart Poettering <lennart@poettering.net>
Subject: Re: [PATCH 2/4] cgroup: add bpf hook for attach
Date: Sat, 21 Feb 2026 18:57:24 +0100	[thread overview]
Message-ID: <20260221-salat-meiden-1283869d1038@brauner> (raw)
In-Reply-To: <aZh6vebjDcrccqNP@slm.duckdns.org>

On Fri, Feb 20, 2026 at 05:16:13AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Fri, Feb 20, 2026 at 01:38:30AM +0100, Christian Brauner wrote:
> > Add a hook to manage attaching tasks to cgroup. I'm in the process of
> > adding various "universal truth" bpf programs to systemd that will make
> > use of this.
> > 
> > This has been a long-standing request (cf. [1] and [2]). It will allow us to
> > enforce cgroup migrations and ensure that services can never escape their
> > cgroups. This is just one of many use-cases.
> 
> >From cgroup POV, this looks fine to me but I'm curious whether something
> dumber would also work. With CLONE_INTO_CGROUP, cgroup migration isn't
> necessary at all. Would something dumber like a mount option disabling
> cgroup migrations completely work too or would that be too restrictive?

It would be too restrictive. I've played with various policies. For
example, a small set of tasks (like PID 1 or the session manager) are
allowed to move processes between cgroups (detectable via e.g., xattrs).
No other task is allowd. But that's already too restrictive because it
fscks over delegated subcgroups were tasks need to be moved around
(container managers etc.). IOW, any policy must be quite modular and
dynamic so a simple mount option wouldn't cover it.

As a sidenote, there would be other mount options that would be useful
but that currently aren't that easy to support/implement because of the
way cgroupfs (for historical reasons ofc) is architected where it shares
a single superblock.

I have a series (from quite some time ago) that makes cgroupfs truly
multi-instance. It would effectively behave just like tmpfs does. A new
mount gets you a new superblock. But once you have that you can e.g.,
simplify cgroup namespaces as well. I've done that work originally to
support idmapped mounts with cgroupfs but I can't find that branch
anymore.

  reply	other threads:[~2026-02-21 17:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20  0:38 [PATCH 0/4] bpf: add a few hooks for sandboxing Christian Brauner
2026-02-20  0:38 ` [PATCH 1/4] ns: add bpf hooks Christian Brauner
2026-02-23 10:36   ` Matt Bobrowski
2026-02-23 11:12     ` Christian Brauner
2026-02-24  0:15       ` Matt Bobrowski
2026-02-23 12:44   ` Djalal Harouni
2026-02-27 11:04     ` Christian Brauner
2026-02-24  1:16   ` Matt Bobrowski
2026-02-27 10:33     ` Christian Brauner
2026-03-24  5:10       ` Matt Bobrowski
2026-02-24 13:35   ` Matt Bobrowski
2026-02-27 14:33     ` Christian Brauner
2026-03-24  5:27       ` Matt Bobrowski
2026-02-24 23:04   ` Song Liu
2026-02-27 10:28     ` Christian Brauner
2026-02-27 16:38       ` Song Liu
2026-03-02  9:46         ` Christian Brauner
2026-03-03 16:44           ` Song Liu
2026-02-20  0:38 ` [PATCH 2/4] cgroup: add bpf hook for attach Christian Brauner
2026-02-20 15:16   ` Tejun Heo
2026-02-21 17:57     ` Christian Brauner [this message]
2026-02-23 15:47   ` Michal Koutný
2026-02-27 13:44     ` Christian Brauner
2026-03-09 16:45       ` Michal Koutný
2026-02-20  0:38 ` [PATCH 3/4] selftests/bpf: add ns hook selftest Christian Brauner
2026-03-05 17:36   ` Alan Maguire
2026-02-20  0:38 ` [PATCH 4/4] selftests/bpf: add cgroup attach selftests Christian Brauner
2026-03-05 17:43   ` Alan Maguire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260221-salat-meiden-1283869d1038@brauner \
    --to=brauner@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kpsingh@kernel.org \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox