[PATCH bpf] Use call_rcu_hurry() with synchronize_rcu_mult()

[PATCH bpf] Use call_rcu_hurry() with synchronize_rcu_mult()

[Paul E. McKenney]

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().

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Song Liu <song@kernel.org>
Cc: Yonghong Song <yhs@fb.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: KP Singh <kpsingh@kernel.org>
Cc: Stanislav Fomichev <sdf@google.com>
Cc: Hao Luo <haoluo@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: <bpf@vger.kernel.org>
Cc: <netdev@vger.kernel.org>

diff --git a/kernel/bpf/bpf_struct_ops.c b/kernel/bpf/bpf_struct_ops.c
index d3f0a4825fa6..bacffd6cae60 100644
--- a/kernel/bpf/bpf_struct_ops.c
+++ b/kernel/bpf/bpf_struct_ops.c
@@ -634,7 +634,7 @@ static void bpf_struct_ops_map_free(struct bpf_map *map)
 	 * in the tramopline image to finish before releasing
 	 * the trampoline image.
 	 */
-	synchronize_rcu_mult(call_rcu, call_rcu_tasks);
+	synchronize_rcu_mult(call_rcu_hurry, call_rcu_tasks);
 
 	__bpf_struct_ops_map_free(map);
 }

Re: [PATCH bpf] Use call_rcu_hurry() with synchronize_rcu_mult()

[Martin KaFai Lau]

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.

Re: [PATCH bpf] Use call_rcu_hurry() with synchronize_rcu_mult()

[Paul E. McKenney]

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