From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: rientjes@google.com
Cc: kosaki.motohiro@gmail.com, kosaki.motohiro@jp.fujitsu.com,
akpm@linux-foundation.org, kamezawa.hiroyu@jp.fujitsu.com,
linux-mm@kvack.org
Subject: Re: [patch] mm, mempolicy: make mempolicies robust against errors
Date: Wed, 07 Mar 2012 11:24:42 -0500 [thread overview]
Message-ID: <4F578BCA.1090706@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1203062253150.1427@chino.kir.corp.google.com>
On 3/7/2012 1:56 AM, David Rientjes wrote:
> On Wed, 7 Mar 2012, KOSAKI Motohiro wrote:
>
>> 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.
>
> It's a different topic, the proposal here is whether an error in
> mempolicies (either the code or flipped bit) should crash the kernel or
> not since it's a condition that can easily be recovered from and leave
> BUG() to errors that actually are fatal. Crashing the kernel offers no
> advantage.
Should crash? The code path never reach. thus there is no ideal behavior.
In this case, BUG() is just unreachable annotation. So let's just annotate
unreachable() even though CONFIG_BUG=n.
WARN_ON_ONCE makes code broat and no positive impact.
--
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-07 20:08 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 [this message]
2012-03-07 21:06 ` David Rientjes
2012-03-08 23:51 ` Andrew Morton
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=4F578BCA.1090706@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@gmail.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.