All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	bpf@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>
Subject: Re: [PATCH bpf-next 1/2] bpf: Pass the same orig_call value to trampoline functions
Date: Thu, 15 May 2025 00:46:22 +0200	[thread overview]
Message-ID: <07d1180a55dc2a589bc0df0895447ba52284cabc.camel@linux.ibm.com> (raw)
In-Reply-To: <ab1d5047-7926-43ae-9dd7-0824b75af8b7@linux.dev>

On Wed, 2025-05-14 at 14:26 -0700, Martin KaFai Lau wrote:
> On 5/12/25 1:57 PM, Ilya Leoshkevich wrote:
> > There is currently some confusion in the s390x JIT regarding
> > whether
> > orig_call can be NULL and what that means. Originally the NULL
> > value
> > was used to distinguish the struct_ops case, but this was
> > superseded by
> > BPF_TRAMP_F_INDIRECT (see commit 0c970ed2f87c ("s390/bpf: Fix
> > indirect
> > trampoline generation").
> > 
> > The remaining reason to have this check is that NULL can actually
> > be
> > passed to the arch_bpf_trampoline_size() call - but not to the
> > respective arch_prepare_bpf_trampoline()! call - by
> > bpf_struct_ops_prepare_trampoline().
> > 
> > Remove this asymmetry by passing stub_func to both functions, so
> > that
> > JITs may rely on orig_call never being NULL.
> > 
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> >   kernel/bpf/bpf_struct_ops.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/bpf/bpf_struct_ops.c
> > b/kernel/bpf/bpf_struct_ops.c
> > index db13ee70d94d..96113633e391 100644
> > --- a/kernel/bpf/bpf_struct_ops.c
> > +++ b/kernel/bpf/bpf_struct_ops.c
> > @@ -601,7 +601,7 @@ int bpf_struct_ops_prepare_trampoline(struct
> > bpf_tramp_links *tlinks,
> >   	if (model->ret_size > 0)
> >   		flags |= BPF_TRAMP_F_RET_FENTRY_RET;
> >   
> > -	size = arch_bpf_trampoline_size(model, flags, tlinks,
> > NULL);
> > +	size = arch_bpf_trampoline_size(model, flags, tlinks,
> > stub_func);
> 
> The change looks ok but not sure why it is needed.
> 
> I can see why stub_func is needed to generate the final image in 
> arch_prepare_bpf_trampoline() in x86. The
> "arch_bpf_trampoline_size()" here is 
> generating a temporary image, so NULL or not doesn't seem to matter.
> 
> Does the s390 jit need to use the actual stub_func address somewhere
> in the 
> temporary and/or final image?

Not right now, however, in the future I would like to check whether
orig_call points to a BPF prog. I have explained the rationale behind
this in the series description.

Purely practical issues aside, currently it's unclear what
orig_func == NULL means. It had meaning in the past, but not anymore.
I think it would be good to remove this uncertainty and state that
today orig_func is never NULL.

Furthermore, a hypothetical JIT may produce different instruction
sequences for loading certain constants. Suppose we wanted to load
the value of orig_call into a register. Then in the NULL case a JIT
could generate:

  xgr %r1,%r1

and in the non-NULL case:

  llihf %r1,<high>
  oilf %r1,<low>

As you mentioned, arch_bpf_trampoline_size() generates a temporary
image, and in this case it would have a different size. So this
asymmetry can be a potential footgun.

  reply	other threads:[~2025-05-14 22:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-12 20:57 [PATCH bpf-next 0/2] s390/bpf: Remove the orig_call NULL check Ilya Leoshkevich
2025-05-12 20:57 ` [PATCH bpf-next 1/2] bpf: Pass the same orig_call value to trampoline functions Ilya Leoshkevich
2025-05-14 21:26   ` Martin KaFai Lau
2025-05-14 22:46     ` Ilya Leoshkevich [this message]
2025-05-14 23:30       ` Martin KaFai Lau
2025-05-12 20:57 ` [PATCH bpf-next 2/2] s390/bpf: Remove the orig_call NULL check Ilya Leoshkevich
2025-05-15  1:00 ` [PATCH bpf-next 0/2] " patchwork-bot+netdevbpf

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=07d1180a55dc2a589bc0df0895447ba52284cabc.camel@linux.ibm.com \
    --to=iii@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=martin.lau@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.