On Thu, Nov 07, 2019 at 12:09:49PM +0530, Amol Grover wrote: > On Thu, Nov 07, 2019 at 07:19:27AM +0700, Phong Tran wrote: > > On 11/6/19 11:56 PM, Amol Grover wrote: [ . . . ] > > > We instead need the rcu_barrier() primitive. Rather than waiting for > > > a grace period to elapse, rcu_barrier() waits for all outstanding RCU > > > -callbacks to complete. Please note that rcu_barrier() does -not- imply > > > +callbacks to complete. Please note that rcu_barrier() does **not** imply > > > synchronize_rcu(), in particular, if there are no RCU callbacks queued > > > anywhere, rcu_barrier() is within its rights to return immediately, > > > without waiting for a grace period to elapse. > > > @@ -89,78 +94,78 @@ module uses multiple flavors of call_rcu(), then it must also use multiple > > > flavors of rcu_barrier() when unloading that module. For example, if > > > it uses call_rcu(), call_srcu() on srcu_struct_1, and call_srcu() on > > > srcu_struct_2(), then the following three lines of code will be required > > > > Hello Amol, > > > > srcu_struct_2() should be srcu_struct_2 > > Hey Phong, > Thanks for the review! Fixed and sent the new patch > https://lore.kernel.org/lkml/20191107063241.GA2234@workstation-kernel-dev/ Phong, please let us know whether Amol's new version looks good to you. If it does, preferably with your Reviewed-by and/or Tested by. ;-) Thanx, Paul
