linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Robert Love <rml@tech9.net>
To: Craig Kulesa <ckulesa@as.arizona.edu>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@zip.com.au>,
	Ed Tomlinson <tomlins@cam.org>
Subject: Re: slablru for 2.5.32-mm1
Date: 06 Sep 2002 00:24:54 -0400	[thread overview]
Message-ID: <1031286298.940.37.camel@phantasy> (raw)
In-Reply-To: <Pine.LNX.4.44.0209052032410.30628-100000@loke.as.arizona.edu>

On Fri, 2002-09-06 at 00:07, Craig Kulesa wrote:

> I have a terribly naive question to add though.  From the original message 
> in this thread, Andrew reverted this BUG_ON due to side-effects:
> 
> 	BUG_ON(smp_call_function(func, arg, 1, 1));
> 
> I must be dense -- why?  All we are doing is passing gcc the hint that
> this is an unlikely path, and surely that's true?  I mean, if it's not, 
> don't we have other things to worry about?

It is just good practice, because it is feasible that one day someone
will do something like:

	#ifdef CONFIG_NO_ASSERT
	#define BUG_ON()		do { } while(0)
	#else
	#define BUG_ON(condition)	do { \
		if (unlikely((condition)!=0)) BUG(); \
	} while(0)
	#endif

so if your BUG_ON has a side effect (e.g. is a function we _have_ to
call, then it needs to be of the normal if..BUG() form.  Note, sure, it
should still be marked unlikely).

	Robert Love


--
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/

  reply	other threads:[~2002-09-06  4:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-06  4:07 Craig Kulesa
2002-09-06  4:24 ` Robert Love [this message]
2002-09-08 21:43   ` Daniel Phillips
2002-09-09  4:36     ` Robert Love
2002-09-09  5:10       ` Daniel Phillips
2002-09-06  4:38 ` Andrew Morton
2002-09-06 11:39   ` Ed Tomlinson
2002-09-06 18:57     ` Craig Kulesa
  -- strict thread matches above, loose matches on Subject: below --
2002-08-28 22:11 Ed Tomlinson
2002-08-26 22:09 MM patches against 2.5.31 Ed Tomlinson
2002-08-26 23:58 ` Andrew Morton
2002-08-28 17:06   ` slablru for 2.5.32-mm1 Ed Tomlinson
2002-08-28 21:24     ` Andrew Morton
2002-08-28 22:23       ` Rik van Riel
2002-09-02  5:26     ` Andrew Morton
2002-09-02 15:00       ` Ed Tomlinson
2002-09-02 18:35         ` Andrew Morton
2002-09-02 19:09           ` Ed Tomlinson
2002-09-02 19:51             ` Andrew Morton
2002-09-02  6:50     ` Andrew Morton

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=1031286298.940.37.camel@phantasy \
    --to=rml@tech9.net \
    --cc=akpm@zip.com.au \
    --cc=ckulesa@as.arizona.edu \
    --cc=linux-mm@kvack.org \
    --cc=tomlins@cam.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