Messages in this thread | | | From | Yosry Ahmed <> | Date | Mon, 10 Oct 2022 12:57:34 -0700 | Subject | Re: [PATCH] cgroup: Fix crash with CLONE_INTO_CGROUP and v1 cgroups |
| |
On Mon, Oct 10, 2022 at 12:51 PM Tejun Heo <tj@kernel.org> wrote: > > Hello, > > On Mon, Oct 10, 2022 at 11:50:50AM -0700, Yosry Ahmed wrote: > > The purpose of f3a2aebdd6 was to make cgroup_get_from_fd() support > > cgroup1, which IIUC makes sense. It was unrelated to IDs. > > Ah, right you are. For some reason, I thought this was ID based. > > > There are currently two users of > > cgroup_get_from_file()/cgroup_get_from_fd() AFAICT, one of which is > > the fork code fixed by this commit, the second is BPF cgroup prog > > attachment. I can send another patch to add explicit filtering in the > > BPF attachment code as well. > > > > Alternatively, we can have separate functions that do the filtering if > > needed. For example: > > cgroup_get_from_fd() / cgroup_get_from_file() -> support both v1 and v2 > > cgroup_get_dfl_from_fd() / cgroup_get_dfl_from_file() -> support only v2 > > > > We can then use the versions with filtering for all the current users > > except cgroup_iter (that needs to support both v1 and v2). WDYT? > > Yes, but please leave the existing ones v2 only and add new ones which > allows cgroup1 too.
Any suggestions for the new names though? Given that the new ones would be the ones that will support both versions, I am not sure how to name them differently in a meaningful way. Maybe something like cgroup_get_all_from_[fd/file]() ?
IMO, we can rename the current versions to cgroup_get_dfl_from_[fd/file](), and the new ones (which support both) as cgroup_get_from_fd/file(). In this case it's obvious that one version specifically works on "dfl", aka cgroup2.
Alternatively, we can have separate versions for v1, cgroup1_get_from_[fd/file](), but then callers that want both v1 and v2 will have to make 2 separate calls unnecessarily.
Thoughts?
> > Thanks. > > -- > tejun
| |