Merge branch 'transfer-rcu-lock-state-across-subprog-calls'
authorAlexei Starovoitov <ast@kernel.org>
Tue, 6 Feb 2024 04:00:14 +0000 (20:00 -0800)
committerAlexei Starovoitov <ast@kernel.org>
Tue, 6 Feb 2024 04:00:14 +0000 (20:00 -0800)
commit20a286c1a35ba4dc2fca5d4c1fb2e7ced101e576
tree5633630512456d6639125786010e2125253f83eb
parent8244ab509f89d63941d5ee207967c5a3e00bb493
parent8be6a0147af314fd60db9da2158cd737dc6394a7
Merge branch 'transfer-rcu-lock-state-across-subprog-calls'

Kumar Kartikeya Dwivedi says:

====================
Transfer RCU lock state across subprog calls

David suggested during the discussion in [0] that we should handle RCU
locks in a similar fashion to spin locks where the verifier understands
when a lock held in a caller is released in callee, or lock taken in
callee is released in a caller, or the callee is called within a lock
critical section. This set extends the same semantics to RCU read locks
and adds a few selftests to verify correct behavior. This issue has also
come up for sched-ext programs.

This would now allow static subprog calls to be made without errors
within RCU read sections, for subprogs to release RCU locks of callers
and return to them, or for subprogs to take RCU lock which is later
released in the caller.

  [0]: https://lore.kernel.org/bpf/20240204120206.796412-1-memxor@gmail.com

Changelog:
----------
v1 -> v2:
v1: https://lore.kernel.org/bpf/20240204230231.1013964-1-memxor@gmail.com

 * Add tests for global subprog behaviour (Yafang)
 * Add Acks, Tested-by (Yonghong, Yafang)
====================

Link: https://lore.kernel.org/r/20240205055646.1112186-1-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>