Michael S. Tsirkin wrote:This makes sense Is it? I don't see where RCU actually enters the equation if you are not bracketing the dereference with rcu_read_lock/unlock. I'm sure you have this correct, its just that it goes against my understanding of how to use RCU properly so I am trying to understand what you did. I'm CC'ing Paul to see if he has any thoughts. I am not sure if we are talking about the same thing, here. I still am not seeing it. Even rcupdate.h says: /** * rcu_dereference - fetch an RCU-protected pointer in an * RCU read-side critical section. This pointer may later * be safely dereferenced. note the "in an RCU read-side critical section". See inline for more comments. Normally you do this inside a read-side critical section, denoted by something like rcu_read_lock/unlock. I do not see this critical section occurring (or am I missing it?). If this truly is not a critical section, either the rcu_dereference is gratuitous, or you have some funky trick up your sleeve ;) If its a trick, please explain it so us mere mortals can understand. I think I understand what your comment above meant: You don't need to do synchronize_rcu() because you can flush the workqueue instead to ensure that all readers have completed. But if thats true, to me, the rcu_dereference itself is gratuitous, and that pointer is *not* actually RCU protected (nor does it need to be).