rcu: remove SPARSE_RCU_POINTER
Subsystems (2)
PATCH 1/1 rcu: remove SPARSE_RCU_POINTER
As I known, __rcu annotations do not effect the result compiled kernel.
They work only when we use spare("make C=1" or "make C=2"), So we don't need another new switch for it since we have one for debugging(use spare or not).
---
include/linux/compiler.h +0 -4
@@ -16,11 +16,7 @@# define __release (x) __context__(x,-1)# define __cond_lock (x,c) ((c) ? ({ __acquire(x); 1; }) : 0)# define __percpu __attribute__((noderef, address_space(3))) -#ifdef CONFIG_SPARSE_RCU_POINTER # define __rcu __attribute__((noderef, address_space(4))) -#else -# define __rcu -#endif extern void __chk_user_ptr (const volatile void __user *);extern void __chk_io_ptr (const volatile void __iomem *);#else
lib/Kconfig.debug +0 -15
@@ -563,21 +563,6 @@ config PROVE_RCU_REPEATEDLY Say N if you are unsure. -config SPARSE_RCU_POINTER - bool "RCU debugging: sparse-based checks for pointer usage" - default n - help - This feature enables the __rcu sparse annotation for - RCU-protected pointers. This annotation will cause sparse - to flag any non-RCU used of annotated pointers. This can be - helpful when debugging RCU usage. Please note that this feature - is not intended to enforce code cleanliness; it is instead merely - a debugging aid. - - Say Y to make sparse flag questionable use of RCU-protected pointers - - Say N if you are unsure. - config LOCKDEP bool depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
Quoted 7 lines · On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
As I known,
__rcuannotations do not effect the result compiled kernel.They work only when we use
spare("make C=1" or "make C=2"), So we don't need another new switch for it since we have one for debugging(use spare or not).Signed-off-by Lai Jiangshan <[email protected]>
The intention of this option was to avoid introducing an excessive number of false positives when using sparse.
We should only make that unconditional if we are reasonably convinced that all the majority of warnings caused by it should actually lead to changes in the code.
Arnd
Quoted 7 lines · Arnd Bergmann
Quoted 6 lines · On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
As I known,
__rcuannotations do not effect the result compiled kernel.They work only when we use
spare("make C=1" or "make C=2"), So we don't need another new switch for it since we have one for debugging(use spare or not).
Quoted 8 lines
Quoted 1 line
Signed-off-by Lai Jiangshan <[email protected]>The intention of this option was to avoid introducing an excessive number of false positives when using sparse.
We should only make that unconditional if we are reasonably convinced that all the majority of warnings caused by it should actually lead to changes in the code.
I agree with Arnd here -- the changes required are extensive in many cases, and a number of subsystems are making decent progress.
Thanx, Paul
Quoted 13 lines · Paul E. McKenney
Quoted 12 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
As I known,
__rcuannotations do not effect the result compiled kernel.They work only when we use
spare("make C=1" or "make C=2"), So we don't need another new switch for it since we have one for debugging(use spare or not).Signed-off-by Lai Jiangshan <[email protected]>The intention of this option was to avoid introducing an excessive number of false positives when using sparse.
Quoted 8 lines
Quoted 3 lines
We should only make that unconditional if we are reasonably convinced that all the majority of warnings caused by it should actually lead to changes in the code.
I agree with Arnd here -- the changes required are extensive in many cases, and a number of subsystems are making decent progress.
Thanx, Paul
I also agree. Most guys like to use direct read to the rcu pointer on update side or direct read/write when initializing the rcu pointer. This causes a lot of false positives.
Thanks,
Lai
Quoted 18 lines · Lai Jiangshan
Quoted 17 lines · Paul E. McKenney
Quoted 15 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
As I known,
__rcuannotations do not effect the result compiled kernel.They work only when we use
spare("make C=1" or "make C=2"), So we don't need another new switch for it since we have one for debugging(use spare or not).Signed-off-by Lai Jiangshan <[email protected]>The intention of this option was to avoid introducing an excessive number of false positives when using sparse.
We should only make that unconditional if we are reasonably convinced that all the majority of warnings caused by it should actually lead to changes in the code.
Quoted 8 lines
Quoted 4 lines
I agree with Arnd here -- the changes required are extensive in many cases, and a number of subsystems are making decent progress.
Thanx, Paul
I also agree. Most guys like to use direct read to the rcu pointer on update side or direct read/write when initializing the rcu pointer. This causes a lot of false positives.
And it is good to see some people, most notably Eric Dumazet, making good use of __rcu! We will learn from the experiences of the early adopters, and perhaps be more aggressive pushing __rcu out to the rest of the community in a year or two, depending on how it goes.
It is quite possible that __rcu will be something that only some of the maintainers make use of for some time -- and that is OK.
Thanx, Paul