On Tue, Oct 04, 2022 at 03:04:19AM +0800, 5486 wrote: > Dear Pualmack i have problem. > I have been reading the patch > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel?id=ab4720ec76b756e1f8705e207a7b392b0453afd6 > > > > + wait_for_completion(&rcu_barrier_completion); > > How this guarantees all completes to be done ? > I learn one wait_for_completion corresponds to one x->done++ once a time 2005! That takes me back a bit! Adding the rcu email list on CC to archive this and for others to weigh in. The trick is that rcu_barrier_callback() is an RCU callback that executes on each CPU (see the on_each_cpu() in the rcu_barrier() function.) This RCU callback function is queued using call_rcu(), which queues that callback at the end of the CPU's callback list. Thus, all RCU callback functions that were already queued on that CPU will be invoked before rcu_barrier_callback() in invoked. The rcu_barrier_callback() does an atomic_dec_and_test() operation on the rcu_barrier_cpu_count global variable, and only when this variable becomes zero does it invoke complete(). This atomic_dec_and_test() operation is fully ordered, and thus ensures that all the earlier atomic_dec_and_test() operations on this variable are globally seen to happen before the last such operation (the one that decrements rcu_barrier_cpu_count to zero). This last rcu_barrier_callback() will then invoke complete(). This will ensure that the wakeup in wait_for_completion() happens only after all previously queued RCU callbacks are invoked. Almost, anyway. There are rare but real race-condition bugs in this ancient version of rcu_barrier(). Can you tell me what they are? Thanx, Paul
