From: Andrew Morton <akpm@linux-foundation.org>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: David Rientjes <rientjes@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org
Subject: Re: [patch] mm, mempolicy: make mempolicies robust against errors
Date: Thu, 8 Mar 2012 15:51:39 -0800 [thread overview]
Message-ID: <20120308155139.19f0ce7e.akpm@linux-foundation.org> (raw)
In-Reply-To: <4F570168.6050008@gmail.com>
On Wed, 07 Mar 2012 01:34:16 -0500
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
> >> And, now BUG() has renreachable() annotation. why don't it work?
> >>
> >>
> >> #define BUG() \
> >> do { \
> >> asm volatile("ud2"); \
> >> unreachable(); \
> >> } while (0)
> >>
> >
> > That's not compiled for CONFIG_BUG=n; such a config fallsback to
> > include/asm-generic/bug.h which just does
> >
> > #define BUG() do {} while (0)
> >
> > because CONFIG_BUG specifically _wants_ to bypass BUG()s and is reasonably
> > protected by CONFIG_EXPERT.
>
> So, I strongly suggest to remove CONFIG_BUG=n. It is neglected very long time and
> much plenty code assume BUG() is not no-op. I don't think we can fix all place.
>
> Just one instruction don't hurt code size nor performance.
Well yes, CONFIG_BUG=n is a crazy thing to do. a) because programmers
universally assume that BUG() doesn't return and b) given that the
kernel KNOWS that it is about to fall off a cliff, why would anyone
want to deprive themselves of information about the forthcoming crash?
So perhaps a good compromise here is to do nothing: let the
CONFIG_BUG=n build spew a pile of warnings, and let the crazy
CONFIG_BUG=n people suffer. That's if any such people exist...
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-03-08 23:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-04 21:43 [patch] mm, mempolicy: dummy slab_node return value for bugless kernels David Rientjes
2012-03-06 20:15 ` Rafael Aquini
2012-03-07 0:08 ` Andrew Morton
2012-03-07 0:55 ` Rafael Aquini
2012-03-07 4:25 ` David Rientjes
2012-03-07 4:29 ` [patch] mm, mempolicy: make mempolicies robust against errors David Rientjes
2012-03-07 5:30 ` KOSAKI Motohiro
2012-03-07 5:58 ` David Rientjes
2012-03-07 6:34 ` KOSAKI Motohiro
2012-03-07 6:56 ` David Rientjes
2012-03-07 16:24 ` KOSAKI Motohiro
2012-03-07 21:06 ` David Rientjes
2012-03-08 23:51 ` Andrew Morton [this message]
2012-04-26 14:58 ` Christoph Lameter
2012-03-07 11:12 ` [patch] mm, mempolicy: dummy slab_node return value for bugless kernels Glauber Costa
2012-03-07 21:04 ` David Rientjes
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=20120308155139.19f0ce7e.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.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 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.