* [PATCH] rcu: remove SPARSE_RCU_POINTER
@ 2011-01-04 8:43 Lai Jiangshan
2011-01-04 10:36 ` Arnd Bergmann
0 siblings, 1 reply; 5+ messages in thread
From: Lai Jiangshan @ 2011-01-04 8:43 UTC (permalink / raw)
To: Paul E. McKenney, Arnd Bergmann, Ingo Molnar, LKML
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).
signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 320d6c9..0ab21c2 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -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
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8be18e5..bf9c5d3 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -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
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] rcu: remove SPARSE_RCU_POINTER
2011-01-04 8:43 [PATCH] rcu: remove SPARSE_RCU_POINTER Lai Jiangshan
@ 2011-01-04 10:36 ` Arnd Bergmann
2011-01-04 21:19 ` Paul E. McKenney
0 siblings, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2011-01-04 10:36 UTC (permalink / raw)
To: Lai Jiangshan; +Cc: Paul E. McKenney, Ingo Molnar, LKML
On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
> 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).
>
> signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] rcu: remove SPARSE_RCU_POINTER
2011-01-04 10:36 ` Arnd Bergmann
@ 2011-01-04 21:19 ` Paul E. McKenney
2011-01-05 1:30 ` Lai Jiangshan
0 siblings, 1 reply; 5+ messages in thread
From: Paul E. McKenney @ 2011-01-04 21:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Lai Jiangshan, Ingo Molnar, LKML
On Tue, Jan 04, 2011 at 11:36:02AM +0100, Arnd Bergmann wrote:
> On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
> > 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).
> >
> > signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] rcu: remove SPARSE_RCU_POINTER
2011-01-04 21:19 ` Paul E. McKenney
@ 2011-01-05 1:30 ` Lai Jiangshan
2011-01-06 5:59 ` Paul E. McKenney
0 siblings, 1 reply; 5+ messages in thread
From: Lai Jiangshan @ 2011-01-05 1:30 UTC (permalink / raw)
To: paulmck; +Cc: Arnd Bergmann, Ingo Molnar, LKML
On 01/05/2011 05:19 AM, Paul E. McKenney wrote:
> On Tue, Jan 04, 2011 at 11:36:02AM +0100, Arnd Bergmann wrote:
>> On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
>>> 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).
>>>
>>> signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>>
>> 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
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] rcu: remove SPARSE_RCU_POINTER
2011-01-05 1:30 ` Lai Jiangshan
@ 2011-01-06 5:59 ` Paul E. McKenney
0 siblings, 0 replies; 5+ messages in thread
From: Paul E. McKenney @ 2011-01-06 5:59 UTC (permalink / raw)
To: Lai Jiangshan; +Cc: Arnd Bergmann, Ingo Molnar, LKML
On Wed, Jan 05, 2011 at 09:30:24AM +0800, Lai Jiangshan wrote:
> On 01/05/2011 05:19 AM, Paul E. McKenney wrote:
> > On Tue, Jan 04, 2011 at 11:36:02AM +0100, Arnd Bergmann wrote:
> >> On Tuesday 04 January 2011 09:43:01 Lai Jiangshan wrote:
> >>> 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).
> >>>
> >>> signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> >>
> >> 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
>
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-01-06 6:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-04 8:43 [PATCH] rcu: remove SPARSE_RCU_POINTER Lai Jiangshan
2011-01-04 10:36 ` Arnd Bergmann
2011-01-04 21:19 ` Paul E. McKenney
2011-01-05 1:30 ` Lai Jiangshan
2011-01-06 5:59 ` Paul E. McKenney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox