On Wed, Nov 6, 2024 at 6:42 PM Yonghong Song <yonghong.song@xxxxxxxxx> wrote: > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 2284b909b499..09bb9dc939d6 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -6278,6 +6278,10 @@ static int check_max_stack_depth(struct bpf_verifier_env *env) > return ret; > } > } > + and patch 6 adds this line here: + env->prog->aux->priv_stack_requested = false; > + if (si[0].priv_stack_mode == PRIV_STACK_ADAPTIVE) > + env->prog->aux->priv_stack_requested = true; > + which makes the above hard to reason about. I think the root of the problem is the dual meaning of the priv_stack_requested flag. On one side it's a way for sched-ext to ask bpf core to enable priv stack, and on the other side it's a request from bpf core to bpf jit to allocate it. I think it's better to split these two conditions. Extra bool is cheap. How about 'bool priv_stack_requested' will be used by sched-ext only and patch 6 largely stays as-is. While patch 1 drops the introduction of priv_stack_requested flag. Instead 'bool jits_use_priv_stack' is introduced in the patch 2 and used by JITs to allocate priv stack. I know we use 'jit_requested' to tell JITs to jit it, so we can bike shed on alternative ways to name these two flags. > return 0; > } > > @@ -20211,6 +20215,9 @@ static int jit_subprogs(struct bpf_verifier_env *env) > > func[i]->aux->name[0] = 'F'; > func[i]->aux->stack_depth = env->subprog_info[i].stack_depth; > + if (env->subprog_info[i].priv_stack_mode == PRIV_STACK_ADAPTIVE) > + func[i]->aux->priv_stack_requested = true; > + > func[i]->jit_requested = 1; > func[i]->blinding_requested = prog->blinding_requested; > func[i]->aux->kfunc_tab = prog->aux->kfunc_tab; > -- > 2.43.5 >
