From: Yonghong Song <yonghong.song@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <kernel-team@fb.com>,
Martin KaFai Lau <martin.lau@kernel.org>,
Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH bpf-next v10 2/7] bpf: Enable private stack for eligible subprogs
Date: Fri, 8 Nov 2024 13:41:36 -0800 [thread overview]
Message-ID: <f1241234-4c52-4b11-ba4b-0a064b9a6874@linux.dev> (raw)
In-Reply-To: <CAADnVQ+Y0Gj-S43oh5MXm71e=qDdRhK7FcigctLGg2TD3n5GkA@mail.gmail.com>
On 11/8/24 11:11 AM, Alexei Starovoitov wrote:
> On Wed, Nov 6, 2024 at 6:42 PM Yonghong Song <yonghong.song@linux.dev> 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.
You are right. I use the same priv_stack_requested to do two things.
>
> 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.
Two bool's approach sound good to me. As you mentioned, two bool's
are not expensive and can make logic cleaner. Will do in the next
revision.
>
>> 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
>>
next prev parent reply other threads:[~2024-11-08 21:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 2:41 [PATCH bpf-next v10 0/7] bpf: Support private stack for bpf progs Yonghong Song
2024-11-07 2:41 ` [PATCH bpf-next v10 1/7] bpf: Find eligible subprogs for private stack support Yonghong Song
2024-11-07 2:41 ` [PATCH bpf-next v10 2/7] bpf: Enable private stack for eligible subprogs Yonghong Song
2024-11-08 19:11 ` Alexei Starovoitov
2024-11-08 21:41 ` Yonghong Song [this message]
2024-11-07 2:41 ` [PATCH bpf-next v10 3/7] bpf, x86: Avoid repeated usage of bpf_prog->aux->stack_depth Yonghong Song
2024-11-07 2:41 ` [PATCH bpf-next v10 4/7] bpf, x86: Support private stack in jit Yonghong Song
2024-11-07 2:42 ` [PATCH bpf-next v10 5/7] selftests/bpf: Add tracing prog private stack tests Yonghong Song
2024-11-07 2:42 ` [PATCH bpf-next v10 6/7] bpf: Support private stack for struct_ops progs Yonghong Song
2024-11-07 19:20 ` Tejun Heo
2024-11-07 2:42 ` [PATCH bpf-next v10 7/7] selftests/bpf: Add struct_ops prog private stack tests Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f1241234-4c52-4b11-ba4b-0a064b9a6874@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox