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 v9 02/10] bpf: Return false for bpf_prog_check_recur() default case
Date: Tue, 5 Nov 2024 08:33:17 -0800 [thread overview]
Message-ID: <43dc0d7d-ca6e-4ba1-a831-e2a1e43f6311@linux.dev> (raw)
In-Reply-To: <CAADnVQK-AXqxEhDwWK=RKx-dA0PZ=N1j6vSshBWS4bGNfv=a7g@mail.gmail.com>
On 11/5/24 7:50 AM, Alexei Starovoitov wrote:
> On Mon, Nov 4, 2024 at 10:02 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>> I also don't understand the point of this patch 2.
>>> The patch 3 can still do:
>>>
>>> + switch (prog->type) {
>>> + case BPF_PROG_TYPE_KPROBE:
>>> + case BPF_PROG_TYPE_TRACEPOINT:
>>> + case BPF_PROG_TYPE_PERF_EVENT:
>>> + case BPF_PROG_TYPE_RAW_TRACEPOINT:
>>> + return PRIV_STACK_ADAPTIVE;
>>> + default:
>>> + break;
>>> + }
>>> +
>>> + if (!bpf_prog_check_recur(prog))
>>> + return NO_PRIV_STACK;
>>>
>>> which would mean that iter, lsm, struct_ops will not be allowed
>>> to use priv stack.
>> One example is e.g. a TC prog. Since bpf_prog_check_recur(prog)
>> will return true (means supporting recursion), and private stack
>> does not really support TC prog, the logic will become more
>> complicated.
>>
>> I am totally okay with removing patch 2 and go back to my
>> previous approach to explicitly list prog types supporting
>> private stack.
> The point of reusing bpf_prog_check_recur() is that we don't
> need to duplicate the logic.
> We can still do something like:
> switch (prog->type) {
> case BPF_PROG_TYPE_KPROBE:
> case BPF_PROG_TYPE_TRACEPOINT:
> case BPF_PROG_TYPE_PERF_EVENT:
> case BPF_PROG_TYPE_RAW_TRACEPOINT:
> return PRIV_STACK_ADAPTIVE;
> case BPF_PROG_TYPE_TRACING:
> case BPF_PROG_TYPE_LSM:
> case BPF_PROG_TYPE_STRUCT_OPS:
> if (bpf_prog_check_recur())
> return PRIV_STACK_ADAPTIVE;
> /* fallthrough */
> default:
> return NO_PRIV_STACK;
> }
Right. Listing trampoline related prog types explicitly
and using bpf_prog_check_recur() will be safe.
One thing is for BPF_PROG_TYPE_STRUCT_OPS, PRIV_STACK_ALWAYS
will be returned. I will make adjustment like
switch (prog->type) {
case BPF_PROG_TYPE_KPROBE:
case BPF_PROG_TYPE_TRACEPOINT:
case BPF_PROG_TYPE_PERF_EVENT:
case BPF_PROG_TYPE_RAW_TRACEPOINT:
return PRIV_STACK_ADAPTIVE;
case BPF_PROG_TYPE_TRACING:
case BPF_PROG_TYPE_LSM:
case BPF_PROG_TYPE_STRUCT_OPS:
if (bpf_prog_check_recur()) {
if (prog->type == BPF_PROG_TYPE_STRUCT_OPS)
return PRIV_STACK_ALWAYS;
else
return PRIV_STACK_ADAPTIVE;
}
/* fallthrough */
default:
return NO_PRIV_STACK;
}
next prev parent reply other threads:[~2024-11-05 16:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 19:34 [PATCH bpf-next v9 00/10] bpf: Support private stack for bpf progs Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 01/10] bpf: Check stack depth limit after visiting all subprogs Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 02/10] bpf: Return false for bpf_prog_check_recur() default case Yonghong Song
2024-11-05 1:21 ` Alexei Starovoitov
2024-11-05 1:35 ` Yonghong Song
2024-11-05 1:55 ` Alexei Starovoitov
2024-11-05 2:53 ` Yonghong Song
2024-11-05 3:50 ` Yonghong Song
2024-11-05 4:28 ` Alexei Starovoitov
2024-11-05 6:02 ` Yonghong Song
2024-11-05 15:50 ` Alexei Starovoitov
2024-11-05 16:33 ` Yonghong Song [this message]
2024-11-05 16:38 ` Alexei Starovoitov
2024-11-05 16:48 ` Yonghong Song
2024-11-05 17:47 ` Alexei Starovoitov
2024-11-04 19:35 ` [PATCH bpf-next v9 03/10] bpf: Allow private stack to have each subprog having stack size of 512 bytes Yonghong Song
2024-11-05 2:47 ` Alexei Starovoitov
2024-11-05 3:09 ` Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 04/10] bpf: Check potential private stack recursion for progs with async callback Yonghong Song
2024-11-05 2:51 ` Alexei Starovoitov
2024-11-05 3:37 ` Yonghong Song
2024-11-05 20:26 ` Alexei Starovoitov
2024-11-05 21:26 ` Yonghong Song
2024-11-05 21:52 ` Alexei Starovoitov
2024-11-06 0:19 ` Yonghong Song
2024-11-06 1:07 ` Alexei Starovoitov
2024-11-06 2:33 ` Yonghong Song
2024-11-06 6:55 ` Yonghong Song
2024-11-06 15:26 ` Alexei Starovoitov
2024-11-06 15:44 ` Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 05/10] bpf: Allocate private stack for eligible main prog or subprogs Yonghong Song
2024-11-05 1:38 ` Alexei Starovoitov
2024-11-05 3:07 ` Yonghong Song
2024-11-05 3:44 ` Yonghong Song
2024-11-05 5:19 ` Alexei Starovoitov
2024-11-05 6:05 ` Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 06/10] bpf, x86: Avoid repeated usage of bpf_prog->aux->stack_depth Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 07/10] bpf, x86: Support private stack in jit Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 08/10] selftests/bpf: Add tracing prog private stack tests Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 09/10] bpf: Support private stack for struct_ops progs Yonghong Song
2024-11-04 19:35 ` [PATCH bpf-next v9 10/10] 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=43dc0d7d-ca6e-4ba1-a831-e2a1e43f6311@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