From: Johannes Weiner <hannes@cmpxchg.org> Date: 2016-09-14 19:53:00
From: Johannes Weiner <redacted>
During cgroup2 rollout into production, we started encountering css
refcount underflows and css access crashes in the memory controller.
Splitting the heavily shared css reference counter into logical users
narrowed the imbalance down to the cgroup2 socket memory accounting.
The problem turns out to be the per-cpu charge cache. Cgroup1 had a
separate socket counter, but the new cgroup2 socket accounting goes
through the common charge path that uses a shared per-cpu cache for
all memory that is being tracked. Those caches are safe against
scheduling preemption, but not against interrupts - such as the newly
added packet receive path. When cache draining is interrupted by
network RX taking pages out of the cache, the resuming drain operation
will put references of in-use pages, thus causing the imbalance.
Disable IRQs during all per-cpu charge cache operations.
Fixes: f7e1cb6ec51b ("mm: memcontrol: account socket memory in unified hierarchy memory controller")
Cc: <redacted> # 4.5+
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/memcontrol.c | 31 ++++++++++++++++++++++---------
1 file changed, 22 insertions(+), 9 deletions(-)
--
2.9.3
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Johannes Weiner <hannes@cmpxchg.org> Date: 2016-09-14 19:53:03
From: Johannes Weiner <redacted>
When a socket is cloned, the associated sock_cgroup_data is duplicated
but not its reference on the cgroup. As a result, the cgroup reference
count will underflow when both sockets are destroyed later on.
Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup")
Cc: <redacted> # 4.5+
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
kernel/cgroup.c | 6 ++++++
net/core/sock.c | 5 ++++-
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.9.3
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Johannes Weiner <hannes@cmpxchg.org> Date: 2016-09-14 19:53:20
The cgroup core and the memory controller need to track socket
ownership for different purposes, but the tracking sites being
entirely different is kind of ugly.
Be a better citizen and rename the memory controller callbacks to
match the cgroup core callbacks, then move them to the same place.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
include/linux/memcontrol.h | 4 ++--
mm/memcontrol.c | 19 +++++++++++--------
net/core/sock.c | 6 +++---
net/ipv4/tcp.c | 2 --
net/ipv4/tcp_ipv4.c | 3 ---
5 files changed, 16 insertions(+), 18 deletions(-)
@@ -2939,7 +2939,7 @@ static int memcg_update_tcp_limit(struct mem_cgroup *memcg, unsigned long limit)/**Theactiveflagneedstobewrittenafterthestatic_key*update.Thisiswhatguaranteesthatthesocketactivation-*functionisthelastonetorun.Seesock_update_memcg()for+*functionisthelastonetorun.Seemem_cgroup_sk_alloc()for*details,andnotethatwedon'tmarkanysocketasbelonging*tothismemcguntilthatflagisup.*
@@ -2948,7 +2948,7 @@ static int memcg_update_tcp_limit(struct mem_cgroup *memcg, unsigned long limit)*asaccounted,buttheaccountingfunctionsarenotpatchedin*yet,we'llloseaccounting.*-*Weneverracewiththereadersinsock_update_memcg(),+*Weneverracewiththereadersinmem_cgroup_sk_alloc(),*becausewhenthisvaluechange,thecodetoprocessitisnot*patchedinyet.*/
@@ -5651,11 +5651,15 @@ void mem_cgroup_migrate(struct page *oldpage, struct page *newpage)DEFINE_STATIC_KEY_FALSE(memcg_sockets_enabled_key);EXPORT_SYMBOL(memcg_sockets_enabled_key);-voidsock_update_memcg(structsock*sk)+voidmem_cgroup_sk_alloc(structsock*sk){structmem_cgroup*memcg;-/* Socket cloning can throw us here with sk_cgrp already+if(!mem_cgroup_sockets_enabled)+return;++/*+*Socketcloningcanthrowusherewithsk_memcgalready*filled.Itwon'thowever,necessarilyhappenfrom*processcontext.Sothetestforrootmemcggiven*thecurrenttask'smemcgwon'thelpusinthiscase.
--
2.9.3
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
On Wed, Sep 14, 2016 at 03:48:46PM -0400, Johannes Weiner wrote:
The cgroup core and the memory controller need to track socket
ownership for different purposes, but the tracking sites being
entirely different is kind of ugly.
Be a better citizen and rename the memory controller callbacks to
match the cgroup core callbacks, then move them to the same place.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
For 1-3,
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: kbuild test robot <hidden> Date: 2016-09-14 21:13:06
Hi Johannes,
[auto build test ERROR on net/master]
[also build test ERROR on v4.8-rc6 next-20160914]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Johannes-Weiner/mm-memcontrol-make-per-cpu-charge-cache-IRQ-safe-for-socket-accounting/20160915-035634
config: parisc-b180_defconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
All errors (new ones prefixed by >>):
net/built-in.o: In function `sk_alloc':
(.text.sk_alloc+0xb4): undefined reference to `mem_cgroup_sk_alloc'
net/built-in.o: In function `__sk_destruct':
quoted
net/core/.tmp_sock.o:(.text.__sk_destruct+0xdc): undefined reference to `mem_cgroup_sk_free'
net/built-in.o: In function `sk_clone_lock':
(.text.sk_clone_lock+0x184): undefined reference to `mem_cgroup_sk_alloc'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
(.text+0x4076): undefined reference to `mem_cgroup_sk_alloc'
net/built-in.o: In function `__sk_destruct':
quoted
sock.c:(.text+0x457e): undefined reference to `mem_cgroup_sk_free'
net/built-in.o: In function `sk_clone_lock':
(.text+0x4f1c): undefined reference to `mem_cgroup_sk_alloc'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
_
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
(.text+0x4076): undefined reference to `mem_cgroup_sk_alloc'
net/built-in.o: In function `__sk_destruct':
quoted
quoted
sock.c:(.text+0x457e): undefined reference to `mem_cgroup_sk_free'
net/built-in.o: In function `sk_clone_lock':
(.text+0x4f1c): undefined reference to `mem_cgroup_sk_alloc'
This?
Thanks for fixing it up, Andrew.
I think it'd be nicer to declare the dummy functions for !CONFIG_MEMCG;
it also doesn't look like a hotpath that would necessitate the jump
label in that place. Dave, any preference either way?
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
From: Michal Hocko <mhocko@kernel.org> Date: 2016-09-19 12:01:47
[Fixup Vladimir's email]
On Wed 14-09-16 15:48:44, Johannes Weiner wrote:
From: Johannes Weiner <redacted>
During cgroup2 rollout into production, we started encountering css
refcount underflows and css access crashes in the memory controller.
Splitting the heavily shared css reference counter into logical users
narrowed the imbalance down to the cgroup2 socket memory accounting.
The problem turns out to be the per-cpu charge cache. Cgroup1 had a
separate socket counter, but the new cgroup2 socket accounting goes
through the common charge path that uses a shared per-cpu cache for
all memory that is being tracked. Those caches are safe against
scheduling preemption, but not against interrupts - such as the newly
added packet receive path. When cache draining is interrupted by
network RX taking pages out of the cache, the resuming drain operation
will put references of in-use pages, thus causing the imbalance.
Disable IRQs during all per-cpu charge cache operations.
Fixes: f7e1cb6ec51b ("mm: memcontrol: account socket memory in unified hierarchy memory controller")
Cc: <redacted> # 4.5+
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Michal Hocko <mhocko@kernel.org> Date: 2016-09-19 12:03:14
[Fixup Vladimir's email]
I am not familiar with this code path to give my ack, unfortunatelly.
On Wed 14-09-16 15:48:45, Johannes Weiner wrote:
quoted hunk
From: Johannes Weiner <redacted>
When a socket is cloned, the associated sock_cgroup_data is duplicated
but not its reference on the cgroup. As a result, the cgroup reference
count will underflow when both sockets are destroyed later on.
Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup")
Cc: <redacted> # 4.5+
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
kernel/cgroup.c | 6 ++++++
net/core/sock.c | 5 ++++-
2 files changed, 10 insertions(+), 1 deletion(-)
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Michal Hocko <mhocko@kernel.org> Date: 2016-09-19 12:04:28
[Fixup Vladimir's email]
same here I do not feel familiar with the code enough to give my ack but
Vladimir might be in a better position
On Wed 14-09-16 15:48:46, Johannes Weiner wrote:
quoted hunk
The cgroup core and the memory controller need to track socket
ownership for different purposes, but the tracking sites being
entirely different is kind of ugly.
Be a better citizen and rename the memory controller callbacks to
match the cgroup core callbacks, then move them to the same place.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
include/linux/memcontrol.h | 4 ++--
mm/memcontrol.c | 19 +++++++++++--------
net/core/sock.c | 6 +++---
net/ipv4/tcp.c | 2 --
net/ipv4/tcp_ipv4.c | 3 ---
5 files changed, 16 insertions(+), 18 deletions(-)
@@ -2939,7 +2939,7 @@ static int memcg_update_tcp_limit(struct mem_cgroup *memcg, unsigned long limit)/**Theactiveflagneedstobewrittenafterthestatic_key*update.Thisiswhatguaranteesthatthesocketactivation-*functionisthelastonetorun.Seesock_update_memcg()for+*functionisthelastonetorun.Seemem_cgroup_sk_alloc()for*details,andnotethatwedon'tmarkanysocketasbelonging*tothismemcguntilthatflagisup.*
@@ -2948,7 +2948,7 @@ static int memcg_update_tcp_limit(struct mem_cgroup *memcg, unsigned long limit)*asaccounted,buttheaccountingfunctionsarenotpatchedin*yet,we'llloseaccounting.*-*Weneverracewiththereadersinsock_update_memcg(),+*Weneverracewiththereadersinmem_cgroup_sk_alloc(),*becausewhenthisvaluechange,thecodetoprocessitisnot*patchedinyet.*/
@@ -5651,11 +5651,15 @@ void mem_cgroup_migrate(struct page *oldpage, struct page *newpage)DEFINE_STATIC_KEY_FALSE(memcg_sockets_enabled_key);EXPORT_SYMBOL(memcg_sockets_enabled_key);-voidsock_update_memcg(structsock*sk)+voidmem_cgroup_sk_alloc(structsock*sk){structmem_cgroup*memcg;-/* Socket cloning can throw us here with sk_cgrp already+if(!mem_cgroup_sockets_enabled)+return;++/*+*Socketcloningcanthrowusherewithsk_memcgalready*filled.Itwon'thowever,necessarilyhappenfrom*processcontext.Sothetestforrootmemcggiven*thecurrenttask'smemcgwon'thelpusinthiscase.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Vladimir Davydov <hidden> Date: 2016-09-19 15:35:55
On Wed, Sep 14, 2016 at 03:48:44PM -0400, Johannes Weiner wrote:
From: Johannes Weiner <redacted>
During cgroup2 rollout into production, we started encountering css
refcount underflows and css access crashes in the memory controller.
Splitting the heavily shared css reference counter into logical users
narrowed the imbalance down to the cgroup2 socket memory accounting.
The problem turns out to be the per-cpu charge cache. Cgroup1 had a
separate socket counter, but the new cgroup2 socket accounting goes
through the common charge path that uses a shared per-cpu cache for
all memory that is being tracked. Those caches are safe against
scheduling preemption, but not against interrupts - such as the newly
added packet receive path. When cache draining is interrupted by
network RX taking pages out of the cache, the resuming drain operation
will put references of in-use pages, thus causing the imbalance.
Disable IRQs during all per-cpu charge cache operations.
Fixes: f7e1cb6ec51b ("mm: memcontrol: account socket memory in unified hierarchy memory controller")
Cc: <redacted> # 4.5+
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Vladimir Davydov <redacted>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Vladimir Davydov <hidden> Date: 2016-09-19 15:43:28
On Wed, Sep 14, 2016 at 03:48:45PM -0400, Johannes Weiner wrote:
From: Johannes Weiner <redacted>
When a socket is cloned, the associated sock_cgroup_data is duplicated
but not its reference on the cgroup. As a result, the cgroup reference
count will underflow when both sockets are destroyed later on.
Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup")
Cc: <redacted> # 4.5+
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Vladimir Davydov <redacted>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>