On 8/16/22 10:55 PM, YiFei Zhu wrote:
Recursive invocation should not happen after commit 86f44fcec22c ("bpf: Disallow bpf programs call prog_run command."), unlike what is suggested in the comment. The only way to I can see this condition trigger is if userspace fetches an fd of a kernel-loaded lskel and attempt to race the kernel to execute that lskel... which also shouldn't happen under normal circumstances. To make this "should never happen" explicit, clarify this in the comment and add a WARN_ON. Fixes: 86f44fcec22c ("bpf: Disallow bpf programs call prog_run command.") Signed-off-by: YiFei Zhu <zhuyifei@xxxxxxxxxx> --- kernel/bpf/syscall.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 27760627370d..9cac9402c0bf 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -5119,8 +5119,8 @@ int kern_sys_bpf(int cmd, union bpf_attr *attr, unsigned int size)run_ctx.bpf_cookie = 0;run_ctx.saved_run_ctx = NULL; - if (!__bpf_prog_enter_sleepable(prog, &run_ctx)) { - /* recursion detected */ + if (WARN_ON(!__bpf_prog_enter_sleepable(prog, &run_ctx))) { + /* recursion detected, should never happen */
Pushed out commit 1/2, thanks! I think this one causes more confusion than value, imho, for example in your commit log you state that it could trigger when attempting to race, in the comment you state "should never happen". Which one is it? Also, if we can recover gracefully in this case, what should the user do with the warn (I guess worst case warn_on_once), but still? Thanks, Daniel
