From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>, <linux-mm@kvack.org>,
<kernel-team@fb.com>, <linux-kernel@vger.kernel.org>,
Roman Gushchin <guro@fb.com>,
Naresh Kamboju <naresh.kamboju@linaro.org>
Subject: [PATCH] mm: slab/memcg: fix build on MIPS
Date: Fri, 17 Jul 2020 14:48:10 -0700 [thread overview]
Message-ID: <20200717214810.3733082-1-guro@fb.com> (raw)
Naresh reported that linux-next build is broken on MIPS. The problem
is reproducible using gcc 8 and 9, but not 10.
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=mips
CROSS_COMPILE=mips-linux-gnu- HOSTCC=gcc CC="sccache
mips-linux-gnu-gcc" O=build
../mm/slub.c: In function ‘slab_alloc.constprop’:
../mm/slub.c:2897:30: error: inlining failed in call to always_inline
‘slab_alloc.constprop’: recursive inlining
2897 | static __always_inline void *slab_alloc(struct kmem_cache *s,
| ^~~~~~~~~~
../mm/slub.c:2905:14: note: called from here
2905 | void *ret = slab_alloc(s, gfpflags, _RET_IP_);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../mm/slub.c: In function ‘sysfs_slab_alias’:
../mm/slub.c:2897:30: error: inlining failed in call to always_inline
‘slab_alloc.constprop’: recursive inlining
2897 | static __always_inline void *slab_alloc(struct kmem_cache *s,
| ^~~~~~~~~~
../mm/slub.c:2905:14: note: called from here
2905 | void *ret = slab_alloc(s, gfpflags, _RET_IP_);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../mm/slub.c: In function ‘sysfs_slab_add’:
../mm/slub.c:2897:30: error: inlining failed in call to always_inline
‘slab_alloc.constprop’: recursive inlining
2897 | static __always_inline void *slab_alloc(struct kmem_cache *s,
| ^~~~~~~~~~
../mm/slub.c:2905:14: note: called from here
2905 | void *ret = slab_alloc(s, gfpflags, _RET_IP_);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The problem was introduced by commit "mem: memcg/slab: use a single
set of kmem_caches for all allocations", which added an allocation
of the space for the obj_cgroup vector into the slab post hook
and created a recursive inlining.
The easies way to fix this is to move memcg_alloc_page_obj_cgroups()
to memcontrol.c and make it a generic (not static inline) function.
It breaks the inlining recursion and fixes the build.
Signed-off-by: Roman Gushchin <guro@fb.com>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
---
mm/memcontrol.c | 20 ++++++++++++++++++++
mm/slab.h | 21 ++-------------------
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 3f49e9bdbf2d..f47e9f0d42f4 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2831,6 +2831,26 @@ static void commit_charge(struct page *page, struct mem_cgroup *memcg)
}
#ifdef CONFIG_MEMCG_KMEM
+int memcg_alloc_page_obj_cgroups(struct page *page, struct kmem_cache *s,
+ gfp_t gfp)
+{
+ unsigned int objects = objs_per_slab_page(s, page);
+ void *vec;
+
+ vec = kcalloc_node(objects, sizeof(struct obj_cgroup *), gfp,
+ page_to_nid(page));
+ if (!vec)
+ return -ENOMEM;
+
+ if (cmpxchg(&page->obj_cgroups, NULL,
+ (struct obj_cgroup **) ((unsigned long)vec | 0x1UL)))
+ kfree(vec);
+ else
+ kmemleak_not_leak(vec);
+
+ return 0;
+}
+
/*
* Returns a pointer to the memory cgroup to which the kernel object is charged.
*
diff --git a/mm/slab.h b/mm/slab.h
index 92a4104b22b3..6cc323f1313a 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -257,25 +257,8 @@ static inline bool page_has_obj_cgroups(struct page *page)
return ((unsigned long)page->obj_cgroups & 0x1UL);
}
-static inline int memcg_alloc_page_obj_cgroups(struct page *page,
- struct kmem_cache *s, gfp_t gfp)
-{
- unsigned int objects = objs_per_slab_page(s, page);
- void *vec;
-
- vec = kcalloc_node(objects, sizeof(struct obj_cgroup *), gfp,
- page_to_nid(page));
- if (!vec)
- return -ENOMEM;
-
- if (cmpxchg(&page->obj_cgroups, NULL,
- (struct obj_cgroup **) ((unsigned long)vec | 0x1UL)))
- kfree(vec);
- else
- kmemleak_not_leak(vec);
-
- return 0;
-}
+int memcg_alloc_page_obj_cgroups(struct page *page, struct kmem_cache *s,
+ gfp_t gfp);
static inline void memcg_free_page_obj_cgroups(struct page *page)
{
--
2.26.2
reply other threads:[~2020-07-17 21:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200717214810.3733082-1-guro@fb.com \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=naresh.kamboju@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).