From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>, bpf <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 08/10] s390/bpf: Support arena atomics
Date: Fri, 28 Jun 2024 11:09:17 +0200 [thread overview]
Message-ID: <dbf2a9f87eea35af2e1e3101d00833e67cc069db.camel@linux.ibm.com> (raw)
In-Reply-To: <CAADnVQJu6Aci=MGZ2P18=6fydDP+QMiu++PxJ+2aHrnxksg1ag@mail.gmail.com>
On Thu, 2024-06-27 at 17:43 -0700, Alexei Starovoitov wrote:
> On Thu, Jun 27, 2024 at 2:09 AM Ilya Leoshkevich <iii@linux.ibm.com>
> wrote:
> >
> > s390x supports most BPF atomics using single instructions, which
> > makes implementing arena support a matter of adding arena address
> > to
> > the base register (unfortunately atomics do not support index
> > registers), and wrapping the respective native instruction in
> > probing
> > sequences.
> >
> > An exception is BPF_XCHG, which is implemented using two different
> > memory accesses and a loop. Make sure there is enough extable
> > entries
> > for both instructions. Compute the base address once for both
> > memory
> > accesses. Since on exception we need to land after the loop, emit
> > the
> > nops manually.
> >
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> > arch/s390/net/bpf_jit_comp.c | 100
> > +++++++++++++++++++++++++++++++----
> > 1 file changed, 91 insertions(+), 9 deletions(-)
[...]
> > +
> > +bool bpf_jit_supports_insn(struct bpf_insn *insn, bool in_arena)
> > +{
> > + /*
> > + * Currently the verifier uses this function only to check
> > which
> > + * atomic stores to arena are supported, and they all are.
> > + */
> > + return true;
>
> Including all the multi insn instructions that are implemented as
> loops?
> On x86 I left out atomic+fetch+[and|or|xor],
> because they're tricky with looping.
> Just checking that when an exception happens
> the loop is not going to become infinite ?
> If I'm reading the code correctly the exception handling will not
> only
> skip one insn, but will skip the whole loop?
On s390x only BPF_XCHG needs to be implemented as a loop, the rest
are single instructions. For example, there is LOAD AND EXCLUSIVE OR,
which is atomic, updates memory, and puts the original value into a
register.
For BPF_XCHG the exception handler will skip the entire loop after
an exception. BPF_XCHG has two memory accesses: the initial LOAD, and
then the COMPARE AND SWAP loop. I wasn't able to test the exception
handling for COMPARE AND SWAP, because I would have to inject a race
that would free the arena page after the initial LOAD.
Now that you asked, I added the following temporary patch to skip the
LOAD:
--- a/arch/s390/net/bpf_jit_comp.c
+++ b/arch/s390/net/bpf_jit_comp.c
@@ -1598,10 +1598,8 @@ static noinline int bpf_jit_insn(struct bpf_jit
*jit, struct bpf_prog *fp,
struct bpf_jit_probe load_probe = probe;
bpf_jit_probe_atomic_pre(jit, insn,
&load_probe);
- /* {ly|lg} %w0,off(%arena) */
- EMIT6_DISP_LH(0xe3000000,
- is32 ? 0x0058 : 0x0004, REG_W0,
REG_0,
- load_probe.arena_reg, off);
+ /* bcr 0,%0 (nop) */
+ _EMIT2(0x0700);
bpf_jit_probe_emit_nop(jit, &load_probe);
/* Reuse {ly|lg}'s arena_reg for {csy|csg}. */
if (load_probe.prg != -1) {
This is still a valid BPF_XCHG implementation, just less efficient in
the non-contended case. The exception handling works, but I found a
bug: the hard-coded offset in
/* brc 4,0b */
EMIT4_PCREL_RIC(0xa7040000, 4, jit->prg - 6);
is no longer valid due to the extra nop added by this patch.
I will fix this and resend.
next prev parent reply other threads:[~2024-06-28 9:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-27 9:07 [PATCH bpf-next 00/10] s390/bpf: Implement arena Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 01/10] s390/bpf: Factor out emitting probe nops Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 02/10] s390/bpf: Get rid of get_probe_mem_regno() Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 03/10] s390/bpf: Introduce pre- and post- probe functions Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 04/10] s390/bpf: Land on the next JITed instruction after exception Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 05/10] s390/bpf: Support BPF_PROBE_MEM32 Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 06/10] s390/bpf: Support address space cast instruction Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 07/10] s390/bpf: Enable arena Ilya Leoshkevich
2024-06-27 9:07 ` [PATCH bpf-next 08/10] s390/bpf: Support arena atomics Ilya Leoshkevich
2024-06-28 0:43 ` Alexei Starovoitov
2024-06-28 9:09 ` Ilya Leoshkevich [this message]
2024-06-27 9:07 ` [PATCH bpf-next 09/10] selftests/bpf: Add UAF tests for " Ilya Leoshkevich
2024-06-28 0:45 ` Alexei Starovoitov
2024-06-28 9:13 ` Ilya Leoshkevich
2024-07-03 2:10 ` kernel test robot
2024-06-27 9:07 ` [PATCH bpf-next 10/10] selftests/bpf: Remove arena tests from DENYLIST.s390x Ilya Leoshkevich
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=dbf2a9f87eea35af2e1e3101d00833e67cc069db.camel@linux.ibm.com \
--to=iii@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=alexei.starovoitov@gmail.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 \
/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.