On Mon, Jan 10, 2022 at 7:33 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Mon, Jan 10, 2022 at 10:55:54AM -0800, Hao Luo wrote: > > > > I see. With attach API, are we also able to specify some attributes > > for the attachment? For example, a property that we may want is: let > > descendent cgroups inherit their parent cgroup's programs. > > Plenty of interesting ideas in this thread. Thanks for kicking it off. > Maybe we should move it to office hours? > The back and forth over email can take some time. > It sounds to me that "let descendents inherit" is a mandatory feature. > In that sense "allow attach in kernfs" is not a feature. It feels that > it's creating more problems for the design. > Creating a "catable" file inside cgroup directory that descedents inherit > with the same name is a cgroup specific feature. > Inherit or not can be a flag, but the inheritance needs to be designed > from the start. > > echo "rm" is not pretty. > fsnotify feels a bit hacky. > Maybe pinning in cgroupfs will avoid both issues? > We can have normal unlink implemented there. With unlink we can do chown and let regular users call unlink. So maybe it's actually more flexible vs syscall detach, although no idea why the users would do that. > The attach bpf_sys cmd as-is won't work. It needs a name at least. Can we use prog_name in attach? Or, if it's limited by BPF_OBJ_NAME_LEN, can we extract function name from btf? Or is it too magic to derive the path from the program name? obj_pin+unlink is a good alternative. One thing I'm not certain is: what happens when I call unlink on some of the inherited nodes? (i.e., do I need to have a flag to say "unlink this one including children/parent"? probably not and returning error is fine?) Agree with your summary that the inheritance story needs more thought :-)
