On 11/3/22 6:04 PM, Alexei Starovoitov wrote:
On 11/3/22 5:30 PM, Yonghong Song wrote:
index 94659f6b3395..e86389cd6133 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -5481,6 +5481,18 @@ union bpf_attr {
* 0 on success.
*
* **-ENOENT** if the bpf_local_storage cannot be found.
+ *
+ * void bpf_rcu_read_lock(void)
+ * Description
+ * Call kernel rcu_read_lock().
+ * Return
+ * None.
+ *
+ * void bpf_rcu_read_unlock(void)
+ * Description
+ * Call kernel rcu_read_unlock().
+ * Return
+ * None.
*/
It would be better to not bake these into UAPI and keep them unstable
only IMO.
rcu_read_lock/unlock() are well known in kernel programming. I think
put them as stable UAPI should be fine. But I will reword the
description to remove any direct reference to kernel functions.
tbh I also feel that kfunc is better here.
Sooner or later we will need srcu_read_lock,
then rcu_read_lock_task_trace, etc.
bpf shouldn't be a burden to RCU.
Okay, I will kfunc then.
