From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: EXYNOS: use BUG_ON where possible
Date: Mon, 12 Nov 2012 15:23:49 +0000 [thread overview]
Message-ID: <20121112152349.GH28327@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <50A111DD.6080504@gmail.com>
On Mon, Nov 12, 2012 at 04:12:29PM +0100, Maarten Lankhorst wrote:
> Op 08-11-12 21:23, Sasha Levin schreef:
> > @@ -465,10 +465,8 @@ static void __init combiner_cascade_irq(unsigned int combiner_nr, unsigned int i
> > else
> > max_nr = EXYNOS4_MAX_COMBINER_NR;
> >
> > - if (combiner_nr >= max_nr)
> > - BUG();
> > - if (irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0)
> > - BUG();
> > + BUG_ON(combiner_nr >= max_nr);
> > + BUG_ON(irq_set_handler_data(irq, &combiner_data[combiner_nr]) != 0);
>
> Is it really a good idea to put functions that perform work in a BUG_ON?
> I don't know, but for some reason it just feels wrong. I'd expect code to
> compile fine if BUG_ON was a noop, so doing verification calls only, not
> actual work..
Well, it is currently defined as:
include/asm-generic/bug.h:#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
include/asm-generic/bug.h:#define BUG_ON(condition) do { if (condition) ; } while(0)
but as these can be overridden, I don't think relying on those
implementations is a good idea; to do so would be fragile. Eg, what if
the BUG_ON() implementation becomes just:
#define BUG_ON(x)
then the function call itself vanishes. So, only put the actual bug test
inside a BUG_ON(), not the functional part which must always be executed.
next prev parent reply other threads:[~2012-11-12 15:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1352406191-14303-1-git-send-email-sasha.levin@oracle.com>
2012-11-08 20:23 ` [PATCH] ARM: gic: use BUG_ON where possible Sasha Levin
2012-11-08 20:23 ` [PATCH] ARM: kprobes: " Sasha Levin
2012-11-09 9:26 ` Jon Medhurst (Tixy)
2012-11-08 20:23 ` [PATCH] ARM: EXYNOS: " Sasha Levin
2012-11-12 15:12 ` Maarten Lankhorst
2012-11-12 15:23 ` Russell King - ARM Linux [this message]
2012-11-12 15:52 ` Sasha Levin
2012-11-12 15:25 ` Sasha Levin
2012-11-08 20:23 ` [PATCH] ARM: integrator: " Sasha Levin
2012-11-12 20:44 ` Arnd Bergmann
2012-11-17 18:41 ` Linus Walleij
2012-11-08 20:23 ` [PATCH] ARM: OMAP1: " Sasha Levin
2012-11-12 23:21 ` Tony Lindgren
2012-11-08 20:23 ` [PATCH] ARM: dma: " Sasha Levin
2012-11-08 20:23 ` [PATCH] ARM: versatile: " Sasha Levin
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=20121112152349.GH28327@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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).