public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: paulmck@linux.vnet.ibm.com, laijs@cn.fujitsu.com,
	manfred@colorfullife.com, dhowells@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu: avoid checking for constant
Date: Thu, 12 Jan 2012 01:52:57 -0800	[thread overview]
Message-ID: <20120112095257.GA2441@leaf> (raw)
In-Reply-To: <alpine.LNX.2.01.1201121018430.31943@frira.zrqbmnf.qr>

On Thu, Jan 12, 2012 at 10:25:23AM +0100, Jan Engelhardt wrote:
> rcu: avoid checking for constant
> 
> When compiling kernel or module code with -O0, "offset" is no longer
> considered a constant, and therefore always triggers the build error
> that BUILD_BUG_ON is defined to yield.
> 
> What is the rationale between the forced constant check,
> introduced in 9ab1544eb4196ca8d05c433b2eb56f74496b1ee3?

This question shouldn't live in the commit message.  Please replace it
with an explanation of the change instead.

> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
> ---
>  include/linux/rcupdate.h |   22 ++++------------------
>  1 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 2cf4226..5e7286d 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -795,24 +795,6 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)
>  #define RCU_INIT_POINTER(p, v) \
>  		p = (typeof(*v) __force __rcu *)(v)
>  
> -static __always_inline bool __is_kfree_rcu_offset(unsigned long offset)
> -{
> -	return offset < 4096;
> -}
> -
> -static __always_inline
> -void __kfree_rcu(struct rcu_head *head, unsigned long offset)
> -{
> -	typedef void (*rcu_callback)(struct rcu_head *);
> -
> -	BUILD_BUG_ON(!__builtin_constant_p(offset));
> -
> -	/* See the kfree_rcu() header comment. */
> -	BUILD_BUG_ON(!__is_kfree_rcu_offset(offset));
> -
> -	call_rcu(head, (rcu_callback)offset);
> -}
> -
>  /**
>   * kfree_rcu() - kfree an object after a grace period.
>   * @ptr:	pointer to kfree
> @@ -836,6 +818,10 @@ void __kfree_rcu(struct rcu_head *head, unsigned long offset)
>   * Note that the allowable offset might decrease in the future, for example,
>   * to allow something like kmem_cache_free_rcu().
>   */
> +#define __kfree_rcu(head, offset) \
> +	call_rcu(head, (void (*)(struct rcu_head *))(unsigned long)(offset) + \
> +		 BUILD_BUG_ON_ZERO((offset) >= 4096))
> +

I had to stare at this for a while, and look up the definition of
BUILD_BUG_ON_ZERO.  Naturally I assumed that BUILD_BUG_ON_ZERO(arg)
meant BUILT_BUG_ON((arg) == 0), which would have made the logic
backwards here.  However, per the definition it just provides a
zero-returning version of BUILD_BUG_ON.  Ow.

In any case, __kfree_rcu has void return type, so how about just using
do { ... } while(0) and BUILD_BUG_ON instead?  That seems significantly
clearer.

Apart from that, I can live with this, though it seems horribly
backwards to replace an inline with a macro rather than the other way
around.

- Josh Triplett

  reply	other threads:[~2012-01-12  9:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-12  5:11 [PATCH] rcu: avoid checking for constant Jan Engelhardt
2012-01-12  7:14 ` Josh Triplett
2012-01-12  9:25   ` Jan Engelhardt
2012-01-12  9:52     ` Josh Triplett [this message]
2012-01-12 10:34       ` Jan Engelhardt
2012-01-12 10:54         ` Eric Dumazet
2012-01-12 10:57           ` Jan Engelhardt
2012-01-12 15:29             ` Paul E. McKenney
2012-01-12 16:08               ` Jan Engelhardt
2012-01-12 16:14                 ` Eric Dumazet
2012-01-12 11:58         ` Josh Triplett
2012-01-12 15:38           ` Jan Engelhardt
2012-01-12 18:41             ` Josh Triplett
2012-04-19 18:57               ` Paul E. McKenney

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=20120112095257.GA2441@leaf \
    --to=josh@joshtriplett.org \
    --cc=dhowells@redhat.com \
    --cc=jengelh@medozas.de \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=paulmck@linux.vnet.ibm.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