Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3035446pxu; Tue, 8 Dec 2020 01:32:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJw6ljqynTNcI8ntSmJxDnAwo3FzbtRI1mjB6r621aLUvuUcg45UvWmS8qc8r4Jt2fjMfyXc X-Received: by 2002:a05:6402:610:: with SMTP id n16mr15823424edv.172.1607419953100; Tue, 08 Dec 2020 01:32:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607419953; cv=none; d=google.com; s=arc-20160816; b=mA6I8K9YOAFHsUxRx0rPgGcLSvxu7GlKSQLiptaWWE6ieEgRVksaqgxgLh2dwnhlBP 1zIsHpx6dNhv7wEas3Krakyrjg8N2bmlCIbSNALBB8PVB4/8rNq4J4OrKpkC6brzUG5M x9/jTBb5zA05ssHewKrY+CiuWX8cjdtS1JGWRmChFp1tAo3jtmxMw58UqzcnPfwxEynI zJb1CBkTlvNI6BfxpunfKAq1ouYk2E5qIPJ/l71gk5yVYiS5a+Ta4/N6jzrIRPaWDQI7 ANC2W6NvvVHOAloA7L/dit4exkGaqYCVuVs8Gcs7AG+LvqNzwSCRVIH1YXW4YGFzdOsM WqCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=YXgYA9CeIM+j5i7wHnRUH6RMd2r+QbmdOpQX79NtK20=; b=GX45cq4tuq+csxFYUuggo5rEBhqJIsUQIGO1ugszbuyMS/VTd8lwBQljgAsqIXWJ1K WBpofx+uKJTvLMOR4KaNUzKrazX9y0xGuQueNHiAIMhjVOcFHfxEJRyyUiqxmjQl4Tbj 0nPCGnOLZakvcvyJzVAExuVq7FV7AAFlmKyfBl/dWK0p8eO2GDZbOfTC2R7jYPbjlVrQ UFq9s1jn0JGOWyCFYzjt+hQZIygW9MW7ZvnFPD9crO/HxZZ+Ze7Sie7xcvD6uj8QTp/l oPls8n9XNSJyAqcTGiZ6cTNgNBT4AyvnKj08qB8qh/539iPCGbKzmpwgmSXdP1rBbD2V JLQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mqYC7iQ7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dn5si8816883ejc.533.2020.12.08.01.32.10; Tue, 08 Dec 2020 01:32:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mqYC7iQ7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728983AbgLHJ1i (ORCPT + 99 others); Tue, 8 Dec 2020 04:27:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725917AbgLHJ1g (ORCPT ); Tue, 8 Dec 2020 04:27:36 -0500 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57BEBC0613D6 for ; Tue, 8 Dec 2020 01:26:56 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id x6so11580715wro.11 for ; Tue, 08 Dec 2020 01:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=YXgYA9CeIM+j5i7wHnRUH6RMd2r+QbmdOpQX79NtK20=; b=mqYC7iQ7YUDJkvX3hxzjnG724VOSfrqn1/fCQ70RUDrjVMya7Nvg+O5VWKT2jO8zfa GVIhxGGGD0dNn3aLIkneJuFy2vtgiWfQf4t1HqBnXTp9h74DNgV3ljygWwyhjzKgDE2B eUDUyiZXEOjvNMMF+Wo0Gwia+0qRFkWXepoTmgUZp3JhvY8DnX30VUzjONykGjKeMCPT L+DEnJkf2fdRx5h9De345u7aRYQZYg/pw/lqhxPQHnkESIvWB/9kSyi5v8l69C0kJExZ t7+BKjx1yMwVqTazbgIOp2S2roy4Rv0JRpop+3GyqZ6VvK22ZLIaZSwhZffRvAohXB/n q0GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YXgYA9CeIM+j5i7wHnRUH6RMd2r+QbmdOpQX79NtK20=; b=HAjj+2I9R9WX/xzRiYdMe09FCtfDNfJNUvHhGEsf3D/SWR5pNhDVUI5BkcFokXN8Ax vkkC7AyG1gXClE29c4OwU35qUClugLK0+O0kXPnhnCHsHaj688qIgmG+twgzEiUs6P18 RfjTRubl2uCZHVjn23uHYS34V7CWHUWt11L7PqoYTpwlJmf5FVg+tPClIdmKSlXNZSXb Y4ELHCyzXg6uZmmlazx1GG1rkUmBqj67GMRj6wRCxWAYWCCFmqrxiEVmBxmF9q2sj61t rmdW1INNXYkidTpBGVOR8R6YXj20swCeFq+cZ75SMoWq2LOl5jsAVgNyssM/6DNQMUSd LnFw== X-Gm-Message-State: AOAM531aWe1Tip2UGIupJ1/+RskezczoKGemAUpSrpsJcG85TR9KL010 IDR60vTUaevBlrFPCelbYYpPSw== X-Received: by 2002:a5d:554e:: with SMTP id g14mr7078158wrw.264.1607419614931; Tue, 08 Dec 2020 01:26:54 -0800 (PST) Received: from google.com (203.75.199.104.bc.googleusercontent.com. [104.199.75.203]) by smtp.gmail.com with ESMTPSA id i9sm12810706wrs.70.2020.12.08.01.26.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Dec 2020 01:26:54 -0800 (PST) Date: Tue, 8 Dec 2020 09:26:50 +0000 From: Brendan Jackman To: John Fastabend Cc: bpf@vger.kernel.org, Alexei Starovoitov , Yonghong Song , Daniel Borkmann , KP Singh , Florent Revest , linux-kernel@vger.kernel.org, Jann Horn Subject: Re: [PATCH bpf-next v4 04/11] bpf: Rename BPF_XADD and prepare to encode other atomics in .imm Message-ID: References: <20201207160734.2345502-1-jackmanb@google.com> <20201207160734.2345502-5-jackmanb@google.com> <5fcea525c4971_5a96208bd@john-XPS-13-9370.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fcea525c4971_5a96208bd@john-XPS-13-9370.notmuch> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi John, thanks a lot for the reviews! On Mon, Dec 07, 2020 at 01:56:53PM -0800, John Fastabend wrote: > Brendan Jackman wrote: > > A subsequent patch will add additional atomic operations. These new > > operations will use the same opcode field as the existing XADD, with > > the immediate discriminating different operations. > > > > In preparation, rename the instruction mode BPF_ATOMIC and start > > calling the zero immediate BPF_ADD. > > > > This is possible (doesn't break existing valid BPF progs) because the > > immediate field is currently reserved MBZ and BPF_ADD is zero. > > > > All uses are removed from the tree but the BPF_XADD definition is > > kept around to avoid breaking builds for people including kernel > > headers. > > > > Signed-off-by: Brendan Jackman > > --- > > Documentation/networking/filter.rst | 30 ++++++++----- > > arch/arm/net/bpf_jit_32.c | 7 ++- > > arch/arm64/net/bpf_jit_comp.c | 16 +++++-- > > arch/mips/net/ebpf_jit.c | 11 +++-- > > arch/powerpc/net/bpf_jit_comp64.c | 25 ++++++++--- > > arch/riscv/net/bpf_jit_comp32.c | 20 +++++++-- > > arch/riscv/net/bpf_jit_comp64.c | 16 +++++-- > > arch/s390/net/bpf_jit_comp.c | 27 ++++++----- > > arch/sparc/net/bpf_jit_comp_64.c | 17 +++++-- > > arch/x86/net/bpf_jit_comp.c | 45 ++++++++++++++----- > > arch/x86/net/bpf_jit_comp32.c | 6 +-- > > drivers/net/ethernet/netronome/nfp/bpf/jit.c | 14 ++++-- > > drivers/net/ethernet/netronome/nfp/bpf/main.h | 4 +- > > .../net/ethernet/netronome/nfp/bpf/verifier.c | 15 ++++--- > > include/linux/filter.h | 29 ++++++++++-- > > include/uapi/linux/bpf.h | 5 ++- > > kernel/bpf/core.c | 31 +++++++++---- > > kernel/bpf/disasm.c | 6 ++- > > kernel/bpf/verifier.c | 24 +++++----- > > lib/test_bpf.c | 14 +++--- > > samples/bpf/bpf_insn.h | 4 +- > > samples/bpf/cookie_uid_helper_example.c | 6 +-- > > samples/bpf/sock_example.c | 2 +- > > samples/bpf/test_cgrp2_attach.c | 5 ++- > > tools/include/linux/filter.h | 28 ++++++++++-- > > tools/include/uapi/linux/bpf.h | 5 ++- > > .../bpf/prog_tests/cgroup_attach_multi.c | 4 +- > > .../selftests/bpf/test_cgroup_storage.c | 2 +- > > tools/testing/selftests/bpf/verifier/ctx.c | 7 ++- > > .../bpf/verifier/direct_packet_access.c | 4 +- > > .../testing/selftests/bpf/verifier/leak_ptr.c | 10 ++--- > > .../selftests/bpf/verifier/meta_access.c | 4 +- > > tools/testing/selftests/bpf/verifier/unpriv.c | 3 +- > > .../bpf/verifier/value_illegal_alu.c | 2 +- > > tools/testing/selftests/bpf/verifier/xadd.c | 18 ++++---- > > 35 files changed, 317 insertions(+), 149 deletions(-) > > > > [...] > > > +++ a/arch/mips/net/ebpf_jit.c > > [...] > > > - if (BPF_MODE(insn->code) == BPF_XADD) { > > + if (BPF_MODE(insn->code) == BPF_ATOMIC) { > > + if (insn->imm != BPF_ADD) { > > + pr_err("ATOMIC OP %02x NOT HANDLED\n", insn->imm); > > + return -EINVAL; > > + } > > + > > /* > [...] > > +++ b/arch/powerpc/net/bpf_jit_comp64.c > > > - case BPF_STX | BPF_XADD | BPF_W: > > + case BPF_STX | BPF_ATOMIC | BPF_W: > > + if (insn->imm != BPF_ADD) { > > + pr_err_ratelimited( > > + "eBPF filter atomic op code %02x (@%d) unsupported\n", > > + code, i); > > + return -ENOTSUPP; > > + } > [...] > > @@ -699,8 +707,15 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, > > - case BPF_STX | BPF_XADD | BPF_DW: > > + case BPF_STX | BPF_ATOMIC | BPF_DW: > > + if (insn->imm != BPF_ADD) { > > + pr_err_ratelimited( > > + "eBPF filter atomic op code %02x (@%d) unsupported\n", > > + code, i); > > + return -ENOTSUPP; > > + } > [...] > > + case BPF_STX | BPF_ATOMIC | BPF_W: > > + if (insn->imm != BPF_ADD) { > > + pr_info_once( > > + "bpf-jit: not supported: atomic operation %02x ***\n", > > + insn->imm); > > + return -EFAULT; > > + } > [...] > > + case BPF_STX | BPF_ATOMIC | BPF_W: > > + case BPF_STX | BPF_ATOMIC | BPF_DW: > > + if (insn->imm != BPF_ADD) { > > + pr_err("bpf-jit: not supported: atomic operation %02x ***\n", > > + insn->imm); > > + return -EINVAL; > > + } > > Can we standardize the error across jits and the error return code? It seems > odd that we use pr_err, pr_info_once, pr_err_ratelimited and then return > ENOTSUPP, EFAULT or EINVAL. That would be a noble cause but I don't think it makes sense in this patchset: they are already inconsistent, so here I've gone for intra-JIT consistency over inter-JIT consistency. I think it would be more annoying, for example, if the s390 JIT returned -EOPNOTSUPP for a bad atomic but -1 for other unsupported ops, than it is already that the s390 JIT returns -1 where the MIPS returns -EINVAL. > granted the error codes might not propagate all the way out at the moment but > still shouldn't hurt. > > > diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c > > index 0a4182792876..f973e2ead197 100644 > > --- a/arch/s390/net/bpf_jit_comp.c > > +++ b/arch/s390/net/bpf_jit_comp.c > > @@ -1205,18 +1205,23 @@ static noinline int bpf_jit_insn(struct bpf_jit *jit, struct bpf_prog *fp, > > For example this will return -1 regardless of error from insn->imm != BPF_ADD. > [...] > > + case BPF_STX | BPF_ATOMIC | BPF_DW: > > + case BPF_STX | BPF_ATOMIC | BPF_W: > > + if (insn->imm != BPF_ADD) { > > + pr_err("Unknown atomic operation %02x\n", insn->imm); > > + return -1; > > + } > > + > [...] > > > --- a/include/linux/filter.h > > +++ b/include/linux/filter.h > > @@ -259,15 +259,38 @@ static inline bool insn_is_zext(const struct bpf_insn *insn) > > .off = OFF, \ > > .imm = 0 }) > > > > -/* Atomic memory add, *(uint *)(dst_reg + off16) += src_reg */ > > + > > +/* > > + * Atomic operations: > > + * > > + * BPF_ADD *(uint *) (dst_reg + off16) += src_reg > > + */ > > + > > +#define BPF_ATOMIC64(OP, DST, SRC, OFF) \ > > + ((struct bpf_insn) { \ > > + .code = BPF_STX | BPF_DW | BPF_ATOMIC, \ > > + .dst_reg = DST, \ > > + .src_reg = SRC, \ > > + .off = OFF, \ > > + .imm = OP }) > > + > > +#define BPF_ATOMIC32(OP, DST, SRC, OFF) \ > > + ((struct bpf_insn) { \ > > + .code = BPF_STX | BPF_W | BPF_ATOMIC, \ > > + .dst_reg = DST, \ > > + .src_reg = SRC, \ > > + .off = OFF, \ > > + .imm = OP }) > > + > > +/* Legacy equivalent of BPF_ATOMIC{64,32}(BPF_ADD, ...) */ > > Not sure I care too much. Does seem more natural to follow > below pattern and use, > > BPF_ATOMIC(OP, SIZE, DST, SRC, OFF) > > > > > #define BPF_STX_XADD(SIZE, DST, SRC, OFF) \ > > ((struct bpf_insn) { \ > > - .code = BPF_STX | BPF_SIZE(SIZE) | BPF_XADD, \ > > + .code = BPF_STX | BPF_SIZE(SIZE) | BPF_ATOMIC, \ > > .dst_reg = DST, \ > > .src_reg = SRC, \ > > .off = OFF, \ > > - .imm = 0 }) > > + .imm = BPF_ADD }) > > > > /* Memory store, *(uint *) (dst_reg + off16) = imm32 */ > > > > [...] > > Otherwise LGTM, I'll try to get the remaining patches reviewed tonight > I need to jump onto something else this afternoon. Thanks!