From: Peter Zijlstra <peterz@infradead.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, Song Liu <song@kernel.org>,
Song Liu <songliubraving@meta.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Sami Tolvanen <samitolvanen@google.com>,
Kees Cook <keescook@chromium.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
clang-built-linux <llvm@lists.linux.dev>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Joao Moreira <joao@overdrivepizza.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call
Date: Fri, 8 Dec 2023 18:21:52 +0100 [thread overview]
Message-ID: <20231208172152.GD36716@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231208134041.GD28727@noisy.programming.kicks-ass.net>
On Fri, Dec 08, 2023 at 02:40:41PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 08, 2023 at 11:29:40AM +0100, Peter Zijlstra wrote:
> > The only problem I now have is the one XXX, I'm not entirely sure what
> > signature to use there.
>
> > @@ -119,6 +119,7 @@ int bpf_struct_ops_test_run(struct bpf_p
> > op_idx = prog->expected_attach_type;
> > err = bpf_struct_ops_prepare_trampoline(tlinks, link,
> > &st_ops->func_models[op_idx],
> > + /* XXX */ NULL,
> > image, image + PAGE_SIZE);
> > if (err < 0)
> > goto out;
>
> Duh, that should ofcourse be something of dummy_ops_test_ret_fn type.
> Let me go fix that.
Next one.. bpf_obj_free_fields: field->kptr.dtor(xchg_field);
The one that trips is bpf_cgroup_release().
objtool doesn't think the address of that function 'escapes' and
'helpfully' seals that function, and then BPF thinks it does escape and
manages the above indirect call and *boom*.
How can I tell which functions escape according to BPF such that I might
teach objtool this?
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, Song Liu <song@kernel.org>,
Song Liu <songliubraving@meta.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Sami Tolvanen <samitolvanen@google.com>,
Kees Cook <keescook@chromium.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
clang-built-linux <llvm@lists.linux.dev>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Joao Moreira <joao@overdrivepizza.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call
Date: Fri, 8 Dec 2023 18:21:52 +0100 [thread overview]
Message-ID: <20231208172152.GD36716@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231208134041.GD28727@noisy.programming.kicks-ass.net>
On Fri, Dec 08, 2023 at 02:40:41PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 08, 2023 at 11:29:40AM +0100, Peter Zijlstra wrote:
> > The only problem I now have is the one XXX, I'm not entirely sure what
> > signature to use there.
>
> > @@ -119,6 +119,7 @@ int bpf_struct_ops_test_run(struct bpf_p
> > op_idx = prog->expected_attach_type;
> > err = bpf_struct_ops_prepare_trampoline(tlinks, link,
> > &st_ops->func_models[op_idx],
> > + /* XXX */ NULL,
> > image, image + PAGE_SIZE);
> > if (err < 0)
> > goto out;
>
> Duh, that should ofcourse be something of dummy_ops_test_ret_fn type.
> Let me go fix that.
Next one.. bpf_obj_free_fields: field->kptr.dtor(xchg_field);
The one that trips is bpf_cgroup_release().
objtool doesn't think the address of that function 'escapes' and
'helpfully' seals that function, and then BPF thinks it does escape and
manages the above indirect call and *boom*.
How can I tell which functions escape according to BPF such that I might
teach objtool this?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-12-08 17:22 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 13:36 [PATCH v2 0/2] x86/bpf: Fix FineIBT vs eBPF Peter Zijlstra
2023-11-30 13:36 ` Peter Zijlstra
2023-11-30 13:36 ` [PATCH v2 1/2] cfi: Flip headers Peter Zijlstra
2023-11-30 13:36 ` Peter Zijlstra
2023-12-04 19:18 ` Sami Tolvanen
2023-12-04 19:18 ` Sami Tolvanen
2023-11-30 13:36 ` [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call Peter Zijlstra
2023-11-30 13:36 ` Peter Zijlstra
2023-12-03 22:56 ` Alexei Starovoitov
2023-12-03 22:56 ` Alexei Starovoitov
2023-12-04 9:13 ` Peter Zijlstra
2023-12-04 9:13 ` Peter Zijlstra
2023-12-04 11:11 ` Peter Zijlstra
2023-12-04 11:11 ` Peter Zijlstra
2023-12-04 12:52 ` Peter Zijlstra
2023-12-04 12:52 ` Peter Zijlstra
2023-12-04 17:25 ` Jiri Olsa
2023-12-04 17:25 ` Jiri Olsa
2023-12-04 18:16 ` Peter Zijlstra
2023-12-04 18:16 ` Peter Zijlstra
2023-12-04 18:33 ` Peter Zijlstra
2023-12-04 18:33 ` Peter Zijlstra
2023-12-04 18:58 ` Sami Tolvanen
2023-12-04 18:58 ` Sami Tolvanen
2023-12-05 1:18 ` Alexei Starovoitov
2023-12-05 1:18 ` Alexei Starovoitov
2023-12-06 15:35 ` Peter Zijlstra
2023-12-06 15:35 ` Peter Zijlstra
2023-12-06 16:38 ` Peter Zijlstra
2023-12-06 16:38 ` Peter Zijlstra
2023-12-06 18:37 ` Peter Zijlstra
2023-12-06 18:37 ` Peter Zijlstra
2023-12-06 21:39 ` Alexei Starovoitov
2023-12-06 21:39 ` Alexei Starovoitov
2023-12-07 9:31 ` Peter Zijlstra
2023-12-07 9:31 ` Peter Zijlstra
2023-12-07 22:32 ` Alexei Starovoitov
2023-12-07 22:32 ` Alexei Starovoitov
2023-12-08 10:29 ` Peter Zijlstra
2023-12-08 10:29 ` Peter Zijlstra
2023-12-08 13:40 ` Peter Zijlstra
2023-12-08 13:40 ` Peter Zijlstra
2023-12-08 17:21 ` Peter Zijlstra [this message]
2023-12-08 17:21 ` Peter Zijlstra
2023-12-08 19:40 ` Alexei Starovoitov
2023-12-08 19:40 ` Alexei Starovoitov
2023-12-08 20:27 ` Peter Zijlstra
2023-12-08 20:27 ` Peter Zijlstra
2023-12-08 20:35 ` Peter Zijlstra
2023-12-08 20:35 ` Peter Zijlstra
2023-12-08 20:41 ` Alexei Starovoitov
2023-12-08 20:41 ` Alexei Starovoitov
2023-12-08 20:52 ` Peter Zijlstra
2023-12-08 20:52 ` Peter Zijlstra
2023-12-08 20:58 ` Alexei Starovoitov
2023-12-08 20:58 ` Alexei Starovoitov
2023-12-08 22:45 ` Peter Zijlstra
2023-12-08 22:45 ` Peter Zijlstra
2023-12-09 4:51 ` Alexei Starovoitov
2023-12-09 4:51 ` Alexei Starovoitov
2023-12-08 19:32 ` Alexei Starovoitov
2023-12-08 19:32 ` Alexei Starovoitov
2023-12-08 20:18 ` Peter Zijlstra
2023-12-08 20:18 ` Peter Zijlstra
2023-12-08 20:45 ` Alexei Starovoitov
2023-12-08 20:45 ` Alexei Starovoitov
2023-12-08 20:56 ` Peter Zijlstra
2023-12-08 20:56 ` Peter Zijlstra
2023-12-08 21:04 ` Alexei Starovoitov
2023-12-08 21:04 ` Alexei Starovoitov
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=20231208172152.GD36716@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=haoluo@google.com \
--cc=hpa@zytor.com \
--cc=joao@overdrivepizza.com \
--cc=john.fastabend@gmail.com \
--cc=jpoimboe@kernel.org \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=martin.lau@linux.dev \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=olsajiri@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samitolvanen@google.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=songliubraving@meta.com \
--cc=tglx@linutronix.de \
--cc=x86@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 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.