Re: [linux-next:master 6618/6917] kernel/sched/psi.c:1230:13: sparse: error: incompatible types in comparison expression (different address spaces)

[Andrew Morton <akpm@linux-foundation.org>]

> > 
> > Paul, can you please shed light?
> 
> First, please avoid using rcu_dereference_raw() where possible.  It is
> intended for situations where the developer cannot easily state what
> is to be protecting access to an RCU-protected data structure.  So...
> 
> 1.	If the access needs to be within an RCU read-side critical
> 	section, use rcu_dereference().  With the new consolidated
> 	RCU flavors, an RCU read-side critical section is entered
> 	using rcu_read_lock(), anything that disables bottom halves,
> 	anything that disables interrupts, or anything that disables
> 	preemption.
> 
> 2.	If the access might be within an RCU read-side critical section
> 	on the one hand, or protected by (say) my_lock on the other,
> 	use rcu_dereference_check(), for example:
> 	
> 		p1 = rcu_dereference_check(p->rcu_protected_pointer,
> 					   lockdep_is_held(&my_lock));
> 
> 
> 3.	If the access might be within an RCU read-side critical section
> 	on the one hand, or protected by either my_lock or your_lock on
> 	the other, again use rcu_dereference_check(), for example:
> 
> 		p1 = rcu_dereference_check(p->rcu_protected_pointer,
> 					   lockdep_is_held(&my_lock) ||
> 					   lockdep_is_held(&your_lock));
> 
> 4.	If the access is on the update side, so that it is always protected
> 	by my_lock, use rcu_dereference_protected():
> 
> 		p1 = rcu_dereference_protected(p->rcu_protected_pointer,
> 					       lockdep_is_held(&my_lock));
> 
> 	This can be extended to handle multiple locks as in #3 above,
> 	and both can be extended to check other conditions as well.
> 
> 5.	If the protection is supplied by the caller, and is thus unknown
> 	to this code, that is when you use rcu_dereference_raw().  Or
> 	I suppose you could use it when the lockdep expression would be
> 	excessively complex, except that a better approach in that case
> 	might be to take a long hard look at your synchronization design.
> 	Still, there are data-locking cases where any one of a very
> 	large number of locks or reference counters suffices to protect the
> 	pointer, so rcu_derefernce_raw() does have its place.
> 
> 	However, its place is probably quite a bit smaller than one
> 	might expect given the number of uses in the current kernel.
> 	Ditto for its synonym, rcu_dereference_protected( ... , 1).  :-/

Is this documented anywhere (apart from here?)

> Now on to this sparse checking and what the point of it is.  This sparse
> checking is opt-in.  Its purpose is to catch cases where someone
> mistakenly does something like:
> 
> 	p = q->rcu_protected_pointer;
> 
> When they should have done this instead:
> 
> 	p = rcu_dereference(q->rcu_protected_pointer);
> 
> If you wish to opt into this checking, you need to mark the pointer
> definitions (in this case ->private) with __rcu.  It may also
> be necessary to mark function parameters as well, as is done for
> radix_tree_iter_resume().  If you do not wish to use this checking,
> you should ignore these sparse warnings.
> 
> Unfortunately, I don't know of a way to inform 0-day test robot of
> the various maintainers' opt-in/out choices.

Oh geeze.

Good luck, Suren ;)