On 5/23/19 10:58 AM, Roman Gushchin wrote: > On Wed, May 22, 2019 at 10:47:24PM -0700, Yonghong Song wrote: >> >> >> On 5/22/19 4:20 PM, Roman Gushchin wrote: >>> Add a kselftest to cover bpf auto-detachment functionality. >>> The test creates a cgroup, associates some resources with it, >>> attaches a couple of bpf programs and deletes the cgroup. >>> >>> Then it checks that bpf programs are going away in 5 seconds. >>> >>> Expected output: >>> $ ./test_cgroup_attach >>> #override:PASS >>> #multi:PASS >>> #autodetach:PASS >>> test_cgroup_attach:PASS >>> >>> On a kernel without auto-detaching: >>> $ ./test_cgroup_attach >>> #override:PASS >>> #multi:PASS >>> #autodetach:FAIL >>> test_cgroup_attach:FAIL >> >> I ran this problem without both old and new kernels and >> both get all PASSes. My testing environment is a VM. >> Could you specify how to trigger the above failure? > > Most likely you're running cgroup v1, so the memory controller > is not enabled on unified hierarchy. You need to pass > "cgroup_no_v1=all systemd.unified_cgroup_hierarchy=1" > as boot time options to run fully on cgroup v2. I tested on a cgroup v2 machine and it indeed failed without the core patch. Thanks! > > But generally speaking, the lifecycle of a dying cgroup is > completely implementation-defined. No guarantees are provided. > So false positives are fine here, and shouldn't be considered as > something bad. > > At the end all we want it to detach programs in a reasonable time > after rmdir. > > Btw, thank you for the careful review of the patchset. I'll > address your comments, add acks and will send out v3. > > Thanks! >
