On Thu, Feb 01, 2018 at 03:27:14PM -0800, Eric Dumazet wrote:
> Well, this memcg stuff is so confusing.
>
> My recollection is that we had :
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=d979a39d7242e0601bf9b60e89628fb8ac577179
>
>
Well, this memcg stuff is so confusing.
My recollection is that we had :
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=d979a39d7242e0601bf9b60e89628fb8ac577179
On Thu, Feb 01, 2018 at 01:17:56PM -0800, Eric Dumazet wrote:
> On Thu, Feb 1, 2018 at 12:22 PM, Roman Gushchin wrote:
> > On Thu, Feb 01, 2018 at 10:16:55AM -0500, David Miller wrote:
> >> From: Roman Gushchin
> >> Date: Wed, 31 Jan 2018 21:54:08 +
> >>
> >> > So I
On Thu, Feb 1, 2018 at 12:22 PM, Roman Gushchin wrote:
> On Thu, Feb 01, 2018 at 10:16:55AM -0500, David Miller wrote:
>> From: Roman Gushchin
>> Date: Wed, 31 Jan 2018 21:54:08 +
>>
>> > So I really start thinking that reverting 9f1c2674b328
>> > ("net: memcontrol:
On Thu, Feb 01, 2018 at 10:16:55AM -0500, David Miller wrote:
> From: Roman Gushchin
> Date: Wed, 31 Jan 2018 21:54:08 +
>
> > So I really start thinking that reverting 9f1c2674b328
> > ("net: memcontrol: defer call to mem_cgroup_sk_alloc()")
> > and fixing the original issue
From: Roman Gushchin
Date: Wed, 31 Jan 2018 21:54:08 +
> So I really start thinking that reverting 9f1c2674b328
> ("net: memcontrol: defer call to mem_cgroup_sk_alloc()")
> and fixing the original issue differently might be easier
> and a proper way to go. Does it makes sense?
On Thu, Jan 25, 2018 at 12:03:02PM -0500, David Miller wrote:
> From: Roman Gushchin
> Date: Thu, 25 Jan 2018 00:19:11 +
>
> > @@ -476,6 +477,10 @@ struct sock *inet_csk_accept(struct sock *sk, int
> > flags, int *err, bool kern)
> > spin_unlock_bh(>fastopenq.lock);
On Thu, Jan 25, 2018 at 12:03:02PM -0500, David Miller wrote:
> From: Roman Gushchin
> Date: Thu, 25 Jan 2018 00:19:11 +
>
> > @@ -476,6 +477,10 @@ struct sock *inet_csk_accept(struct sock *sk, int
> > flags, int *err, bool kern)
> > spin_unlock_bh(>fastopenq.lock);
From: Roman Gushchin
Date: Thu, 25 Jan 2018 00:19:11 +
> @@ -476,6 +477,10 @@ struct sock *inet_csk_accept(struct sock *sk, int flags,
> int *err, bool kern)
> spin_unlock_bh(>fastopenq.lock);
> }
> mem_cgroup_sk_alloc(newsk);
> + amt =
We've catched several cgroup css refcounting issues on 4.15-rc7,
triggered from different release paths. We've used cgroups v2.
I've added a temporarily per-memcg sockmem atomic counter,
and found, that we're sometimes falling below 0. It was easy
to reproduce, so I was able to bisect the problem.
10 matches
Mail list logo