From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Jan Engelhardt <jengelh@medozas.de>,
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, 19 Apr 2012 11:57:18 -0700 [thread overview]
Message-ID: <20120419185718.GK2472@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120112184150.GA8132@leaf>
On Thu, Jan 12, 2012 at 10:41:50AM -0800, Josh Triplett wrote:
> On Thu, Jan 12, 2012 at 04:38:52PM +0100, Jan Engelhardt wrote:
> > On Thursday 2012-01-12 12:58, Josh Triplett wrote:
> > >> Same impression here. BUILD_BUG_ON_ZERO was introduced by
> > >>
> > >> commit 4552d5dc08b79868829b4be8951b29b07284753f
> > >> Author: Jan Beulich <jbeulich@novell.com>
> > >> Date: Mon Jun 26 13:57:28 2006 +0200
> > >>
> > >> while Rusty's CCAN archive calls it "BUILD_BUG_OR_ZERO" (since either
> > >> it's a bug, or returning neutral zero).
> > >
> > >Sounds like a good target for a fix at some point.
> >
> > What names do you propose? I have BUILD_BUG_ON_EXPR for some of my code,
> > though in the kernel, it has both _ON_ZERO and _ON_NULL.
>
> BUILD_BUG_OR_ZERO (and BUILD_BUG_OR_NULL) seem like improvements over
> _ON_ZERO and _ON_NULL; that would remove the ambiguity we both tripped
> over.
>
> > 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.
> >
> > Therefore, change the innards of kfree_rcu so that the offset is not
> > tunneled through a function argument before checking it.
> >
> > Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
>
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
OK, a similar run-in with copy_from_user() convince me that we need
this. (And I was even using default optimization levels!)
Queue for 3.5, with reworked comments and commit log.
Thanx, Paul
------------------------------------------------------------------------
rcu: Make __kfree_rcu() less dependent on compiler choices
Currently, __kfree_rcu() is implemented as an inline function, and
contains a BUILD_BUG_ON() that malfunctions if __kfree_rcu() is compiled
as an out-of-line function. Unfortunately, there are compiler settings
(e.g., -O0) that can result in __kfree_rcu() being compiled out of line,
resulting in annoying build breakage. This commit therefore converts
both __kfree_rcu() and __is_kfree_rcu_offset() from inline functions to
macros to prevent such misbehavior on the part of the compiler.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 20fb776..d5dfb10 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -922,6 +922,21 @@ void __kfree_rcu(struct rcu_head *head, unsigned long offset)
kfree_call_rcu(head, (rcu_callback)offset);
}
+/*
+ * Does the specified offset indicate that the corresponding rcu_head
+ * structure can be handled by kfree_rcu()?
+ */
+#define __is_kfree_rcu_offset(offset) ((offset) < 4096)
+
+/*
+ * Helper macro for kfree_rcu() to prevent argument-expansion eyestrain.
+ */
+#define __kfree_rcu(head, offset) \
+ do { \
+ BUILD_BUG_ON(!__is_kfree_rcu_offset(offset)); \
+ call_rcu(head, (void (*)(struct rcu_head *))(unsigned long)(offset)); \
+ } while (0)
+
/**
* kfree_rcu() - kfree an object after a grace period.
* @ptr: pointer to kfree
@@ -944,6 +959,9 @@ 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().
+ *
+ * The BUILD_BUG_ON check must not involve any function calls, hence the
+ * checks are done in macros here.
*/
#define kfree_rcu(ptr, rcu_head) \
__kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
prev parent reply other threads:[~2012-04-19 18:57 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
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 [this message]
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=20120419185718.GK2472@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dhowells@redhat.com \
--cc=jengelh@medozas.de \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.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.