From: Raj Sahu <rjsu26@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Siddharth Chintamaneni <sidchintamaneni@gmail.com>,
bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Dan Williams <djwillia@vt.edu>,
miloc@vt.edu, ericts@vt.edu, rahult@vt.edu, doniaghazy@vt.edu,
quanzhif@vt.edu, Jinghao Jia <jinghao7@illinois.edu>,
egor@vt.edu, Sai Roop Somaraju <sairoop10@gmail.com>
Subject: Re: [RFC bpf-next v2 3/4] bpf: Runtime part of fast-path termination approach
Date: Tue, 8 Jul 2025 00:07:39 -0700 [thread overview]
Message-ID: <CAM6KYssLVB+Wqw5ptQQufjmV3279AX7ZKhXtkG6OWaM3vWde-Q@mail.gmail.com> (raw)
In-Reply-To: <CAADnVQ+EiaoWUVcN9=Nm=RWJ6XE=Kcm8Q2FYQqWGJ_NsCtyJ=A@mail.gmail.com>
> If we have such bugs that prog in NMI can stall CPU indefinitely
> they need to be fixed independently of fast-execute.
> timed may_goto, tailcalls or whatever may need to have different
> limits when it detects that the prog is running in NMI or with hard irqs
> disabled. Fast-execute doesn't have to be a universal kill-bpf-prog
> mechanism that can work in any context. I think fast-execute
> is for progs that deadlocked in res_spin_lock, faulted arena,
> or were slow for wrong reasons, but not fatal for the kernel reasons.
> imo we can rely on schedule_work() and bpf_arch_text_poke() from there.
> The alternative of clone of all progs and memory waste for a rare case
> is not appealing. Unless we can detect "dangerous" progs and
> clone with fast execute only for them, so that the majority of bpf progs
> stay as single copy.
I just want to confirm that we are on the same page here:
While the RFC we sent was using prog cloning, Kumar's earlier
suggestion of implementing offset tables can avoid the complete
cloning process and the associated memory footprint. Is there
something else which is concerning here in terms of memory overhead?
Regarding the NMI issue, the fast-execute design was meant to take
care of stalling in tracing and other task-context based programs
running slow for some reason. While I do agree with your point that
deadlocks in NMIs should be solved independently, kumar's point of
having several BPF programs needing termination, running in hardIRQ,
puts us in a fix. What should be the way forward here?
next prev parent reply other threads:[~2025-07-08 7:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-14 6:40 [RFC bpf-next v2 0/4] bpf: Fast-Path approach for BPF program Siddharth Chintamaneni
2025-06-14 6:40 ` [RFC bpf-next v2 1/4] bpf: Introduce new structs and struct fields Siddharth Chintamaneni
2025-06-14 6:40 ` [RFC bpf-next v2 2/4] bpf: Generating a stubbed version of BPF program for termination Siddharth Chintamaneni
2025-06-30 12:47 ` Kumar Kartikeya Dwivedi
2025-07-04 17:32 ` Raj Sahu
2025-07-04 18:37 ` Kumar Kartikeya Dwivedi
2025-06-14 6:40 ` [RFC bpf-next v2 3/4] bpf: Runtime part of fast-path termination approach Siddharth Chintamaneni
2025-06-30 12:15 ` Kumar Kartikeya Dwivedi
2025-07-04 17:29 ` Raj Sahu
2025-07-04 19:10 ` Kumar Kartikeya Dwivedi
2025-07-07 17:40 ` Alexei Starovoitov
2025-07-07 19:16 ` Kumar Kartikeya Dwivedi
2025-07-07 20:09 ` Alexei Starovoitov
2025-07-07 22:08 ` Zvi Effron
2025-07-07 22:39 ` Kumar Kartikeya Dwivedi
2025-07-08 7:07 ` Raj Sahu [this message]
2025-07-10 0:54 ` Kumar Kartikeya Dwivedi
2025-06-14 6:40 ` [RFC bpf-next v2 4/4] selftests/bpf: Adds selftests to check termination of long running nested bpf loops Siddharth Chintamaneni
2025-06-30 13:03 ` [RFC bpf-next v2 0/4] bpf: Fast-Path approach for BPF program Kumar Kartikeya Dwivedi
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=CAM6KYssLVB+Wqw5ptQQufjmV3279AX7ZKhXtkG6OWaM3vWde-Q@mail.gmail.com \
--to=rjsu26@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=djwillia@vt.edu \
--cc=doniaghazy@vt.edu \
--cc=eddyz87@gmail.com \
--cc=egor@vt.edu \
--cc=ericts@vt.edu \
--cc=haoluo@google.com \
--cc=jinghao7@illinois.edu \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=miloc@vt.edu \
--cc=quanzhif@vt.edu \
--cc=rahult@vt.edu \
--cc=sairoop10@gmail.com \
--cc=sdf@fomichev.me \
--cc=sidchintamaneni@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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;
as well as URLs for NNTP newsgroup(s).