On Fri, Dec 06, 2019 at 08:35:54PM +0530, madhuparnabhowmik04@xxxxxxxxx wrote: > From: Madhuparna Bhowmik <madhuparnabhowmik04@xxxxxxxxx> > > There are instances in the linux kernel where the prev pointer > of a list is accessed. > Unlike list_next_rcu, a similar macro for accessing the prev > pointer was not present. Interesting patch, but... You lost me on this one. The list_head ->prev pointer is not marked __rcu, so why is sparse complaining? Or is someone trying to use rcu_dereference() or similar on ->prev? If so, it is important to note that both list_del() and list_del_rcu() poision ->prev, so it is not usually safe to access ->prev within an RCU read-side critical section. At the very least, this restriction needs to be called out in the list_prev_rcu() comment header. And that use of rcu_dereference() and friends on the ->prev pointer is almost always the result of confusion, if not a bug. (Or is this some new-to-me use case?) Either way, the big question is how we are sure that the uses of ->prev that sparse is complaining about are in fact safe. More specifically, what have those use cases done to ensure that there will be no invocation of either list_del() or list_del_rcu() on the current element just before the use of ->prev? Here are a couple of possibilities: 1. The list only grows, so list_del() and list_del_rcu() are never ever invoked on it. But even this is not safe because __list_add_rcu() does smp_store_release() only on ->next. The initialization of ->prev is completely unordered with any other initialization, which can result in bugs on lookup/insertion concurrency. So this instead becomes the list being constant. 2. The ->prev pointer is never actually dereferenced, but only compared. One example use case is determining whether the current element is first in the list by comparing its ->prev pointer to the address of the list header. But this use case needs a READ_ONCE(). 3. These accesses are single-threaded, for example while the list is being initialized but before it is exposed to readers or after the list has been rendered inaccessible to readers (and following at least one grace period after that). But in this case, there is no need for rcu_dereference(), so sparse should not be complaining. 4. #3 above, but code is shared with the non-single-threaded case. But then the non-single-threaded code needs to be safe with respect to concurrent insertions and deletions, as called out above. So what am I missing here? Thanx, Paul > Therefore, directly accessing the prev pointer was causing > sparse errors. > One such example is the sparse error in fs/nfs/dir.c > > error: > fs/nfs/dir.c:2353:14: error: incompatible types in comparison expression (different address spaces): > fs/nfs/dir.c:2353:14: struct list_head [noderef] <asn:4> * > fs/nfs/dir.c:2353:14: struct list_head * > > The error is caused due to the following line: > > lh = rcu_dereference(nfsi->access_cache_entry_lru.prev); > > After adding the macro, this error can be fixed as follows: > > lh = rcu_dereference(list_prev_rcu(&nfsi->access_cache_entry_lru)); > > Therefore, we think there is a need to add this macro to rculist.h. > > Suggested-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx> > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik04@xxxxxxxxx> > --- > include/linux/rculist.h | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/include/linux/rculist.h b/include/linux/rculist.h > index 4b7ae1bf50b3..49eef8437753 100644 > --- a/include/linux/rculist.h > +++ b/include/linux/rculist.h > @@ -40,6 +40,12 @@ static inline void INIT_LIST_HEAD_RCU(struct list_head *list) > */ > #define list_next_rcu(list) (*((struct list_head __rcu **)(&(list)->next))) > > +/* > + * return the prev pointer of a list_head in an rcu safe > + * way, we must not access it directly > + */ > +#define list_prev_rcu(list) (*((struct list_head __rcu **)(&(list)->prev))) > + > /* > * Check during list traversal that we are within an RCU reader > */ > -- > 2.17.1 >