All of lore.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 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.