From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Arnaud Ebalard <arno@natisbad.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, cocci@systeme.lip6.fr,
linux-arm-kernel@lists.infradead.org,
Julia Lawall <Julia.Lawall@lip6.fr>
Subject: Re: Warning masked by BUG() when CONFIG_BUG is enabled
Date: Sun, 17 Nov 2013 00:26:51 +0000 [thread overview]
Message-ID: <20131117002651.GX16735@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <87a9h4559j.fsf@natisbad.org>
On Sat, Nov 16, 2013 at 11:52:08PM +0100, Arnaud Ebalard wrote:
> I was kind of curious not to have noticed it during kernel builds for
> armada 370/xp targets. The reason is the following: on my Armada 370/XP
> builds, I had CONFIG_BUG=y which makes BUG() call panic() (which never
> returns).
You're not the first to spot this, and you won't be the last.
Some very experienced kernel hackers have tried to get this fixed and
failed. It seems people actually want the CPU to fall through the
BUG() sites when people disable CONFIG_BUG - which I think is idiotic.
Arnd (and myself) have worked on this problem, and we came up with a
very nice solution which didn't increase the size of the kernel and
didn't make things unsafe. However, it went nowhere.
It's pointless trying to get this fixed - it's just a complete waste of
time because of politics. Find something else to attack. Just ensure
you always have CONFIG_BUG enabled if you want a system which will
produce some kind of report when one of these sites gets hit.
next prev parent reply other threads:[~2013-11-17 0:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-16 22:52 Warning masked by BUG() when CONFIG_BUG is enabled Arnaud Ebalard
2013-11-17 0:26 ` Russell King - ARM Linux [this message]
2013-11-17 0:36 ` Arnaud Ebalard
2013-11-17 14:06 ` [Cocci] " Wolfram Sang
2013-11-17 14:47 ` Julia Lawall
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=20131117002651.GX16735@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=Julia.Lawall@lip6.fr \
--cc=andrew@lunn.ch \
--cc=arno@natisbad.org \
--cc=cocci@systeme.lip6.fr \
--cc=jason@lakedaemon.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=thomas.petazzoni@free-electrons.com \
/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).