All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Andrii Nakryiko <andrii.nakryiko@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>
Subject: Re: [PATCH bpf-next v2 1/2] bpf: Support private stack for bpf progs
Date: Tue, 23 Jul 2024 21:32:28 -0700	[thread overview]
Message-ID: <78edbafd-ecca-4ed6-97d5-a557b4b2bcf4@linux.dev> (raw)
In-Reply-To: <CAADnVQKXujv9+zf5fbL0cXkxRrFct=JAEjCsr3+FvpArTmcQTQ@mail.gmail.com>


On 7/23/24 8:17 PM, Alexei Starovoitov wrote:
> On Mon, Jul 22, 2024 at 8:27 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
>>>> We *need to support recursion* is my main point.
>>> Not quite.
>>> It's not a recursion. The stack collapsed/gone/wiped out before tail_call.
>> Only of subprog(), not of handle_tp(). See all those "ENTRY - AFTER"
>> messages. We do return to all the nested handle_tp() calls and
>> continue just fine.
>>
>> I put the log into [0] for a bit easier visual inspection.
>>
>>    [0] https://gist.github.com/anakryiko/6ccdfc62188f8ad4991641fb637d954c
> Argh. So the pathological prog can consume 512*33 of stack.

We have a check in verifier like below:

         if (idx && subprog[idx].has_tail_call && depth >= 256) {
                 verbose(env,
                         "tail_calls are not allowed when call stack of previous frames is %d bytes. Too large\n",
                         depth);
                 return -EACCES;
         }

So the maximum stack size could be around 256 * 33 which is a little bit more than 8KB.

> We have to reject it somehow in the verifier or tailor private stack
> to support it. Then private stack will be a feature and a fix for this issue.
> But then it would need to preallocate 512*33 per cpu per program.
> Which is too much.
> Maybe we can preallocate _aligned_ 512 or 1k per cpu per prog,
> then adjust r9 before call or tail_call and if r9 is about to cross
> alignment before tail_call fail the tail call (like tail call cnt was
> over limit).
> Hopefully there are better ideas, since it's all quite messy.

  parent reply	other threads:[~2024-07-24  4:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-18 20:51 [PATCH bpf-next v2 1/2] bpf: Support private stack for bpf progs Yonghong Song
2024-07-18 20:52 ` [PATCH bpf-next v2 2/2] [no_merge] selftests/bpf: Benchmark runtime performance with private stack Yonghong Song
2024-07-18 21:44   ` Yonghong Song
2024-07-18 21:59     ` Kumar Kartikeya Dwivedi
2024-07-19  3:01       ` Yonghong Song
2024-07-19  0:36     ` Alexei Starovoitov
2024-07-19  2:21       ` Yonghong Song
2024-07-20  0:14   ` bot+bpf-ci
2024-07-20  1:08   ` Alexei Starovoitov
2024-07-22 16:33     ` Yonghong Song
2024-07-20  3:28 ` [PATCH bpf-next v2 1/2] bpf: Support private stack for bpf progs Andrii Nakryiko
2024-07-22 16:43   ` Yonghong Song
2024-07-24  5:08     ` Yonghong Song
2024-07-24 16:54       ` Alexei Starovoitov
2024-07-24 17:56         ` Yonghong Song
2024-07-22 20:57   ` Andrii Nakryiko
2024-07-23  1:05     ` Alexei Starovoitov
2024-07-23  3:26       ` Andrii Nakryiko
2024-07-24  3:17         ` Alexei Starovoitov
2024-07-24  4:06           ` Andrii Nakryiko
2024-07-24  4:46             ` Yonghong Song
2024-07-24  4:32           ` Yonghong Song [this message]
2024-07-23  5:30       ` Yonghong Song
2024-07-23  7:02         ` Yonghong Song
2024-07-22  3:33 ` Eduard Zingerman
2024-07-22 16:54   ` Yonghong Song
2024-07-22 17:53     ` Eduard Zingerman
2024-07-22 17:51   ` Alexei Starovoitov
2024-07-22 18:22     ` Eduard Zingerman
2024-07-22 20:08       ` Alexei Starovoitov
2024-07-24 21:28   ` Yonghong Song
2024-07-25  4:55     ` Alexei Starovoitov
2024-07-25 17:20       ` Eduard Zingerman

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=78edbafd-ecca-4ed6-97d5-a557b4b2bcf4@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.