From: Chuck Ebbert <cebbert.lkml@gmail.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: Build regressions/improvements in v3.17-rc6 (take two)
Date: Tue, 23 Sep 2014 05:09:59 -0500 [thread overview]
Message-ID: <20140923051000.60355643@as> (raw)
In-Reply-To: <1411461080-4061-1-git-send-email-geert@linux-m68k.org>
On Tue, 23 Sep 2014 10:31:20 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> + /scratch/kisskb/src/mm/memcontrol.c: warning: control reaches end of non-void function [-Wreturn-type]: => 4164:1
Well, this one was educational. It was caused by:
commit 05b8430123359886ef6a4146fba384e30d771b3f
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Wed Aug 6 16:05:59 2014 -0700
mm: memcontrol: use root_mem_cgroup res_counter
This removed the return statement from mem_cgroup_read_u64(). I think
Johannes was assuming that BUG() never returns, but it looks like that
is not true on some archs, especially with CONFIG_BUG disabled. (On x86
it never returns in any case.) The bug was always there - it would have
just returned an uninitialized variable before. Now it returns some
different random value.
I'm not sure what to do here. I really think BUG() should never return
no matter what options are configured. In this case it's no big deal
and I'd just return zero to silence the warning, but a bigger problem
is that there are probably other places assuming BUG() never
returns?
next prev parent reply other threads:[~2014-09-23 10:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 8:31 Build regressions/improvements in v3.17-rc6 (take two) Geert Uytterhoeven
2014-09-23 8:53 ` Geert Uytterhoeven
2014-09-23 10:09 ` Chuck Ebbert [this message]
2014-09-23 10:23 ` Geert Uytterhoeven
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=20140923051000.60355643@as \
--to=cebbert.lkml@gmail.com \
--cc=geert@linux-m68k.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.