On Sat, Sep 16, 2023 at 1:01 AM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > Hello. > > On Tue, Sep 12, 2023 at 11:30:32AM +0800, Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > With the above changes, I think it can meet most use cases with BPF on cgroup1. > > What do you think ? > > I think the presented use case of LSM hooks is better served by the > default hierarchy (see also [1]). Hi Michal, The crucial issue at hand is not whether the LSM hooks are better suited for the cgroup default hierarchy. What truly matters is the effort and time required to migrate all cgroup1-based applications to cgroup2-based ones. While transitioning a single component from cgroup1-based to cgroup2-based is a straightforward task, the complexity arises when multiple interdependent components in a production environment necessitate this transition. In such cases, the work becomes significantly challenging. > Relying on a chosen subsys v1 hierarchy is not systematic. And extending > ancestry checking on named v1 hierarchies seems backwards given > the existence of the default hierarchy. The cgroup becomes active only when it has one or more of its controllers enabled. In a production environment, a task is invariably governed by at least one cgroup controller. Even in hybrid cgroup mode, a task is subject to either a cgroup1 controller or a cgroup2 controller. Our objective is to enhance BPF support for controller-based scenarios, eliminating the need to concern ourselves with hierarchies, whether they involve cgroup1 or cgroup2. This change seems quite reasonable, in my opinion. > > > Michal > > [1] https://docs.kernel.org/admin-guide/cgroup-v2.html#delegation-containment -- Regards Yafang
