[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpUmajKqeYW9uwtEiFeZGz=q7DFYQT5sq_27yaqoudewuQ@mail.gmail.com>
Date: Fri, 19 Jun 2020 20:00:41 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Roman Gushchin <guro@...com>
Cc: Zefan Li <lizefan@...wei.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Cameron Berkenpas <cam@...-zeon.de>,
Peter Geis <pgwipeout@...il.com>,
Lu Fengqi <lufq.fnst@...fujitsu.com>,
Daniƫl Sonck <dsonck92@...il.com>,
Daniel Borkmann <daniel@...earbox.net>,
Tejun Heo <tj@...nel.org>
Subject: Re: [Patch net] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()
On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin <guro@...com> wrote:
>
> On Sat, Jun 20, 2020 at 09:00:40AM +0800, Zefan Li wrote:
> > I think so, though I'm not familiar with the bfp cgroup code.
> >
> > > If so, we might wanna fix it in a different way,
> > > just checking if (!(css->flags & CSS_NO_REF)) in cgroup_bpf_put()
> > > like in cgroup_put(). It feels more reliable to me.
> > >
> >
> > Yeah I also have this idea in my mind.
>
> I wonder if the following patch will fix the issue?
Interesting, AFAIU, this refcnt is for bpf programs attached
to the cgroup. By this suggestion, do you mean the root
cgroup does not need to refcnt the bpf programs attached
to it? This seems odd, as I don't see how root is different
from others in terms of bpf programs which can be attached
and detached in the same way.
I certainly understand the root cgroup is never gone, but this
does not mean the bpf programs attached to it too.
What am I missing?
Thanks.
Powered by blists - more mailing lists