On Thu, May 18, 2023 at 09:51:39AM -0700, Martin KaFai Lau wrote: > On 5/18/23 7:47 AM, Paul E. McKenney wrote: > > The bpf_struct_ops_map_free() function must wait for both an RCU grace > > period and an RCU Tasks grace period, and so it passes call_rcu() and > > call_rcu_tasks() to synchronize_rcu_mult(). This works, but on ChromeOS > > and Android platforms call_rcu() can have lazy semantics, resulting in > > multi-second delays between call_rcu() invocation and invocation of the > > corresponding callback. > > > > Therefore, substitute call_rcu_hurry() for call_rcu(). > > My understanding on the net-effect is to free up the struct_ops resources faster. > > I believe call_rcu() should be fine. struct_ops freeing should not happen > very often. For example, when a bpf written tcp congestion control > (struct_ops) is registered, it will stay in the kernel for a long time. A > couple seconds delay in releasing the struct_ops should be acceptable. Very good, and sorry for the noise! Thanx, Paul
