Messages in this thread | | | From | Nikolay Borisov <> | Subject | Rcu synchronization of a list | Date | Fri, 27 May 2016 12:40:51 +0300 |
| |
Hello,
I'm currently dealing with a synchronization scheme which utilizes RCU but I'm observing a race condition. So I have an rcu-enabled list, which contains various entries. The add/delete paths of the list are protected by a single spin_lock. I'm observing the following thing happening:
T1 T2 1. init_count 2. delete_group 3.incr_count
So 'init_count' checks the list for a particular entry under rcu_read_lock and will either return the existing one if it finds it, or create a new entry and insert it in the list with the modification spin_lock held. incr_count essentially checks the list again and should return the entry which init_count returned (either the newly created one or the existing entry). However, what I'm observing is an assertion which fires in incr_count because it can't find the entry. The only place where the list is being deleted from is from delete_group.
Having such a scheme what is the correct way to provide synchronization, it seems that op. 1 and 3 need to be atomic w.r.t to op2? Does this fall outside of the scope of the RCU protection scheme?
Regards, Nikolay
| |