On 2020/7/3 0:02, Roman Gushchin wrote:
> On Wed, Jul 01, 2020 at 09:48:48PM -0700, Cong Wang wrote:
>> On Tue, Jun 30, 2020 at 3:48 PM Roman Gushchin wrote:
>>>
>>> Btw if we want to backport the problem but can't blame a specific commit,
>>> we can always use something like "Cc: [3.1+]".
>>
On Thu, Jul 2, 2020 at 12:03 PM Roman Gushchin wrote:
>
> On Wed, Jul 01, 2020 at 09:48:48PM -0700, Cong Wang wrote:
> > On Tue, Jun 30, 2020 at 3:48 PM Roman Gushchin wrote:
> > >
> > > Btw if we want to backport the problem but can't blame a specific commit,
> > > we can always use something li
On Wed, Jul 01, 2020 at 09:48:48PM -0700, Cong Wang wrote:
> On Tue, Jun 30, 2020 at 3:48 PM Roman Gushchin wrote:
> >
> > Btw if we want to backport the problem but can't blame a specific commit,
> > we can always use something like "Cc: [3.1+]".
>
> Sure, but if we don't know which is the r
On 02.07.20 06:48, Cong Wang wrote:
> On Tue, Jun 30, 2020 at 3:48 PM Roman Gushchin wrote:
>>
>> Btw if we want to backport the problem but can't blame a specific commit,
>> we can always use something like "Cc: [3.1+]".
>
> Sure, but if we don't know which is the right commit to blame, then
On Tue, Jun 30, 2020 at 3:48 PM Roman Gushchin wrote:
>
> Btw if we want to backport the problem but can't blame a specific commit,
> we can always use something like "Cc: [3.1+]".
Sure, but if we don't know which is the right commit to blame, then how
do we know which stable version should t
On 2020/7/1 6:48, Roman Gushchin wrote:
> On Tue, Jun 30, 2020 at 03:22:34PM -0700, Cong Wang wrote:
>> On Sat, Jun 27, 2020 at 4:41 PM Roman Gushchin wrote:
>>>
>>> On Fri, Jun 26, 2020 at 10:58:14AM -0700, Cong Wang wrote:
On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas
wrote:
>>>
On Tue, Jun 30, 2020 at 03:22:34PM -0700, Cong Wang wrote:
> On Sat, Jun 27, 2020 at 4:41 PM Roman Gushchin wrote:
> >
> > On Fri, Jun 26, 2020 at 10:58:14AM -0700, Cong Wang wrote:
> > > On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > Somew
On Sat, Jun 27, 2020 at 4:41 PM Roman Gushchin wrote:
>
> On Fri, Jun 26, 2020 at 10:58:14AM -0700, Cong Wang wrote:
> > On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas wrote:
> > >
> > > Hello,
> > >
> > > Somewhere along the way I got the impression that it generally takes
> > > those affect
On Sat, Jun 27, 2020 at 3:59 PM Cameron Berkenpas wrote:
>
> The box has been up without issue for over 25 hours now. The patch seems
> solid.
That's great! Thanks for testing!
On Fri, Jun 26, 2020 at 10:58:14AM -0700, Cong Wang wrote:
> On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas wrote:
> >
> > Hello,
> >
> > Somewhere along the way I got the impression that it generally takes
> > those affected hours before their systems lock up. I'm (generally) able
> > to repr
The box has been up without issue for over 25 hours now. The patch seems
solid.
On 6/26/20 3:03 PM, Cameron Berkenpas wrote:
Box has been up for 25 minutes without issue. Probably the patch
works, but I can further confirm by tomorrow.
On 6/26/2020 10:58 AM, Cong Wang wrote:
On Thu, Jun 25, 2
Box has been up for 25 minutes without issue. Probably the patch works,
but I can further confirm by tomorrow.
On 6/26/2020 10:58 AM, Cong Wang wrote:
On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas wrote:
Hello,
Somewhere along the way I got the impression that it generally takes
those a
On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas wrote:
>
> Hello,
>
> Somewhere along the way I got the impression that it generally takes
> those affected hours before their systems lock up. I'm (generally) able
> to reproduce this issue much faster than that. Regardless, I can help test.
>
>
Hello,
Somewhere along the way I got the impression that it generally takes
those affected hours before their systems lock up. I'm (generally) able
to reproduce this issue much faster than that. Regardless, I can help test.
Are there any patches that need testing or is this all still pending
On Fri, Jun 19, 2020 at 08:31:14PM -0700, Cong Wang wrote:
> On Fri, Jun 19, 2020 at 5:51 PM Zefan Li wrote:
> >
> > 在 2020/6/20 8:45, Zefan Li 写道:
> > > On 2020/6/20 3:51, Cong Wang wrote:
> > >> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
> > >>>
> > >>> On 2020/6/19 5:09, Cong Wang wrote:
On Tue, Jun 23, 2020 at 1:45 AM Zhang,Qiang wrote:
>
> There are some message in kernelv5.4, I don't know if it will help.
>
> demsg:
>
> cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or
> net_cls activation
...
> ---[ cut here ]---
> percpu ref (cgroup_bpf_rele
On Mon, Jun 22, 2020 at 11:14:20AM -0700, Cong Wang wrote:
> On Sat, Jun 20, 2020 at 8:58 AM Roman Gushchin wrote:
> >
> > On Fri, Jun 19, 2020 at 08:00:41PM -0700, Cong Wang wrote:
> > > On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin wrote:
> > > >
> > > > On Sat, Jun 20, 2020 at 09:00:40AM +08
The tester found the following information during the test
The dmesg information is as follows (kernelv5.4) I don't know if it
helps for this question
root@intel-x86-64:~# cgroup: cgroup: disabling cgroup2 socket matching
due to net_prio or net_cls activation
IPv6: ADDRCONF(NETDEV_CHANGE
There are some message in kernelv5.4, I don't know if it will help.
demsg:
cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or
net_cls activation
IPv6: ADDRCONF(NETDEV_CHANGE): veth4c31d8d2: link becomes ready
cni0: port 1(veth4c31d8d2) entered blocking state
cni0: port 1(veth
On Mon, Jun 22, 2020 at 11:14:20AM -0700, Cong Wang wrote:
> On Sat, Jun 20, 2020 at 8:58 AM Roman Gushchin wrote:
> >
> > On Fri, Jun 19, 2020 at 08:00:41PM -0700, Cong Wang wrote:
> > > On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin wrote:
> > > >
> > > > On Sat, Jun 20, 2020 at 09:00:40AM +080
On Sat, Jun 20, 2020 at 8:58 AM Roman Gushchin wrote:
>
> On Fri, Jun 19, 2020 at 08:00:41PM -0700, Cong Wang wrote:
> > On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin wrote:
> > >
> > > On Sat, Jun 20, 2020 at 09:00:40AM +0800, Zefan Li wrote:
> > > > I think so, though I'm not familiar with the
On Sat, Jun 20, 2020 at 03:52:49PM +0800, Zefan Li wrote:
> 在 2020/6/20 11:31, Cong Wang 写道:
> > On Fri, Jun 19, 2020 at 5:51 PM Zefan Li wrote:
> >>
> >> 在 2020/6/20 8:45, Zefan Li 写道:
> >>> On 2020/6/20 3:51, Cong Wang wrote:
> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
> >
> >>>
On Fri, Jun 19, 2020 at 08:00:41PM -0700, Cong Wang wrote:
> On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin 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 d
在 2020/6/20 11:31, Cong Wang 写道:
> On Fri, Jun 19, 2020 at 5:51 PM Zefan Li wrote:
>>
>> 在 2020/6/20 8:45, Zefan Li 写道:
>>> On 2020/6/20 3:51, Cong Wang wrote:
On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
>
> On 2020/6/19 5:09, Cong Wang wrote:
>> On Thu, Jun 18, 2020 at 12:3
On Fri, Jun 19, 2020 at 5:51 PM Zefan Li wrote:
>
> 在 2020/6/20 8:45, Zefan Li 写道:
> > On 2020/6/20 3:51, Cong Wang wrote:
> >> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
> >>>
> >>> On 2020/6/19 5:09, Cong Wang wrote:
> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> >
>
On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin 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 cg
>>> 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?
>
I guess so
On Sat, Jun 20, 2020 at 09:00:40AM +0800, Zefan Li wrote:
> On 2020/6/20 8:51, Roman Gushchin wrote:
> > On Fri, Jun 19, 2020 at 02:40:19PM +0800, Zefan Li wrote:
> >> On 2020/6/19 5:09, Cong Wang wrote:
> >>> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
>
> On Thu, Jun 18, 202
On 2020/6/20 8:51, Roman Gushchin wrote:
> On Fri, Jun 19, 2020 at 02:40:19PM +0800, Zefan Li wrote:
>> On 2020/6/19 5:09, Cong Wang wrote:
>>> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> On Wed, Jun 17, 2020 at
在 2020/6/20 8:45, Zefan Li 写道:
> On 2020/6/20 3:51, Cong Wang wrote:
>> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
>>>
>>> On 2020/6/19 5:09, Cong Wang wrote:
On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
>
> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
>
On Fri, Jun 19, 2020 at 02:40:19PM +0800, Zefan Li wrote:
> On 2020/6/19 5:09, Cong Wang wrote:
> > On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> >>
> >> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> >>> On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
>
> Cc: R
On 2020/6/20 3:51, Cong Wang wrote:
> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
>>
>> On 2020/6/19 5:09, Cong Wang wrote:
>>> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> On Wed, Jun 17, 2020 at 6:44 PM Ze
On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
>
> On 2020/6/19 5:09, Cong Wang wrote:
> > On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> >>
> >> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> >>> On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
>
> Cc: Roman G
On 2020/6/19 5:09, Cong Wang wrote:
> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
>>
>> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
>>> On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
Cc: Roman Gushchin
Thanks for fixing this.
On 2020/6/17
On Thu, Jun 18, 2020 at 5:26 PM Roman Gushchin wrote:
>
> On Thu, Jun 18, 2020 at 02:09:43PM -0700, Cong Wang wrote:
> > On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> > >
> > > On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> > > > On Wed, Jun 17, 2020 at 6:44 PM Zefan Li
On Thu, Jun 18, 2020 at 02:09:43PM -0700, Cong Wang wrote:
> On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> >
> > On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> > > On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
> > > >
> > > > Cc: Roman Gushchin
> > > >
> > > > Thanks f
On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
>
> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> > On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
> > >
> > > Cc: Roman Gushchin
> > >
> > > Thanks for fixing this.
> > >
> > > On 2020/6/17 2:03, Cong Wang wrote:
> > > > Whe
On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
> >
> > Cc: Roman Gushchin
> >
> > Thanks for fixing this.
> >
> > On 2020/6/17 2:03, Cong Wang wrote:
> > > When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> > > copied, so
On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
>
> Cc: Roman Gushchin
>
> Thanks for fixing this.
>
> On 2020/6/17 2:03, Cong Wang wrote:
> > When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> > copied, so the cgroup refcnt must be taken too. And, unlike the
> > sk_alloc() path, so
Cc: Roman Gushchin
Thanks for fixing this.
On 2020/6/17 2:03, Cong Wang wrote:
> When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> copied, so the cgroup refcnt must be taken too. And, unlike the
> sk_alloc() path, sock_update_netprioidx() is not called here.
> Therefore, it is saf
When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
copied, so the cgroup refcnt must be taken too. And, unlike the
sk_alloc() path, sock_update_netprioidx() is not called here.
Therefore, it is safe and necessary to grab the cgroup refcnt
even when cgroup_sk_alloc is disabled.
sk_clone
41 matches
Mail list logo
