* [PATCH] mm/memcontrol: avoid a spurious gcc warning
@ 2016-01-25 15:45 Arnd Bergmann
2016-01-25 18:55 ` Johannes Weiner
0 siblings, 1 reply; 2+ messages in thread
From: Arnd Bergmann @ 2016-01-25 15:45 UTC (permalink / raw)
To: Johannes Weiner, Michal Hocko, Vladimir Davydov
Cc: linux-arm-kernel, Arnd Bergmann, cgroups, linux-mm, linux-kernel
When CONFIG_DEBUG_VM is set, the various VM_BUG_ON() confuse gcc to
the point where it cannot remember that 'memcg' is known to be initialized:
mm/memcontrol.c: In function 'mem_cgroup_can_attach':
mm/memcontrol.c:4791:9: warning: 'memcg' may be used uninitialized in this function [-Wmaybe-uninitialized]
On ARM gcc-5.1, the above happens when any two or more of the VM_BUG_ON()
are active, but not when I remove most or all of them. This is clearly
random behavior and the only way I've found to shut up the warning is
to add an explicit initialization.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
mm/memcontrol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d06cae2de783..9340eb981653 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4762,6 +4762,7 @@ static int mem_cgroup_can_attach(struct cgroup_taskset *tset)
* multiple.
*/
p = NULL;
+ memcg = NULL;
cgroup_taskset_for_each_leader(leader, css, tset) {
WARN_ON_ONCE(p);
p = leader;
--
2.7.0
--
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>
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] mm/memcontrol: avoid a spurious gcc warning
2016-01-25 15:45 [PATCH] mm/memcontrol: avoid a spurious gcc warning Arnd Bergmann
@ 2016-01-25 18:55 ` Johannes Weiner
0 siblings, 0 replies; 2+ messages in thread
From: Johannes Weiner @ 2016-01-25 18:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michal Hocko, Vladimir Davydov, linux-arm-kernel, cgroups,
linux-mm, linux-kernel, Tejun Heo
Hi Arnd,
On Mon, Jan 25, 2016 at 04:45:50PM +0100, Arnd Bergmann wrote:
> When CONFIG_DEBUG_VM is set, the various VM_BUG_ON() confuse gcc to
> the point where it cannot remember that 'memcg' is known to be initialized:
>
> mm/memcontrol.c: In function 'mem_cgroup_can_attach':
> mm/memcontrol.c:4791:9: warning: 'memcg' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> On ARM gcc-5.1, the above happens when any two or more of the VM_BUG_ON()
> are active, but not when I remove most or all of them. This is clearly
> random behavior and the only way I've found to shut up the warning is
> to add an explicit initialization.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks Arnd.
This has been fixed upstream already:
commit eed67d75b66748a498a0592d9704081a98509444
Author: Ross Zwisler <ross.zwisler@linux.intel.com>
Date: Wed Dec 23 14:53:27 2015 -0700
cgroup: Fix uninitialized variable warning
Commit 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration
from subtree_control enabling") introduced the following compiler warning:
mm/memcontrol.c: In function a??mem_cgroup_can_attacha??:
mm/memcontrol.c:4790:9: warning: a??memcga?? may be used uninitialized in this function [-Wmaybe-uninitialized]
mc.to = memcg;
^
Fix this by initializing 'memcg' to NULL.
This was found using gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6).
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
--
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>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-01-25 18:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-25 15:45 [PATCH] mm/memcontrol: avoid a spurious gcc warning Arnd Bergmann
2016-01-25 18:55 ` Johannes Weiner
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).