[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Oct 2022 09:51:51 -1000
From: Tejun Heo <tj@...nel.org>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: "Christian A. Ehrhardt" <lk@...e.de>,
Christian Brauner <brauner@...nel.org>,
syzbot <syzbot+534ee3d24c37c411f37f@...kaller.appspotmail.com>,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
syzkaller-bugs@...glegroups.com,
Martin KaFai Lau <martin.lau@...ux.dev>
Subject: Re: [PATCH] cgroup: Fix crash with CLONE_INTO_CGROUP and v1 cgroups
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.
Thanks.
--
tejun
Powered by blists - more mailing lists