From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F26E4C433F5 for ; Wed, 20 Apr 2022 11:40:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378220AbiDTLnM (ORCPT ); Wed, 20 Apr 2022 07:43:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378219AbiDTLnM (ORCPT ); Wed, 20 Apr 2022 07:43:12 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB0BA419B6 for ; Wed, 20 Apr 2022 04:40:25 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id u7so2463092lfs.8 for ; Wed, 20 Apr 2022 04:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=VKyqkiHMAMbxDabOm41Pe1xqBptH6ILp/RHTVhXWA1M=; b=kisidZ359JBb2iHL/bs4DBq6P+KC4o80zwOVfnjZQHPodqgRP5BAp2fyZ6cZgEt8zE PdNRwdX0xLOeLSG2KLzLVAb5bMVCZ3+gpIhypWAiKJo6XQ5wpokPAE8AtKWXqavhHruc KrCoetQGLT8a6gVZHLHXC+6IPSmqj4aMQYItg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=VKyqkiHMAMbxDabOm41Pe1xqBptH6ILp/RHTVhXWA1M=; b=Dk82MFlJPkc65F06JTWdnbHHa7rq7zzjhq6hmunolBZRFoX6iOhd9ZuyR6p4YfX1kw yHF4ez3LDIRV+fxNK45Ga1s/DZaOCRlsCxpRaycNt5FWiBX/VsUr54QEoykCY10O+ZuX +eO4vqwUxpPDUyJ5Hbnis9GFxDkIUIepMcXo0e1INq+dxDcOFRq7ffv9wKemQ0LsPcMa j4akvry6VuVZBAVXsAwd5FEtNK+Av74ZU0BB215LL7DLvgunO1MaVOQmG7XhXPhg53Ie YTNuH1Q+NRyOdgAz4hM2fDH6sTOqCmyRXY3rfTCoBrjtJCXdxHT8yco13oxiCNjLLsP0 thAQ== X-Gm-Message-State: AOAM530A0s3pqVZzxa8ETQsDTwr4obgWbeYVPWlzAtnbOJBcdY2vXMgE CZ7x28dGvrscxjrMYeBjmINGhQ== X-Google-Smtp-Source: ABdhPJzkCWJhhf8Yp+Zwsj308WiZ2xxy/9KDJBid23/aNj/yJesRU+Lww+2dSgxuR3dGzJ9bPFcfTw== X-Received: by 2002:a05:6512:b1a:b0:471:add8:99e9 with SMTP id w26-20020a0565120b1a00b00471add899e9mr4788534lfu.300.1650454824118; Wed, 20 Apr 2022 04:40:24 -0700 (PDT) Received: from cloudflare.com (79.184.126.143.ipv4.supernova.orange.pl. [79.184.126.143]) by smtp.gmail.com with ESMTPSA id j7-20020a056512028700b00471bab03deesm195633lfp.38.2022.04.20.04.40.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 04:40:23 -0700 (PDT) References: <20211201181040.23337-1-alexei.starovoitov@gmail.com> <20211201181040.23337-6-alexei.starovoitov@gmail.com> User-agent: mu4e 1.6.10; emacs 27.2 From: Jakub Sitnicki To: Alexei Starovoitov Cc: davem@davemloft.net, daniel@iogearbox.net, andrii@kernel.org, bpf@vger.kernel.org, kernel-team@fb.com, kernel-team@cloudflare.com Subject: Re: [PATCH v5 bpf-next 05/17] bpf: Pass a set of bpf_core_relo-s to prog_load command. Date: Wed, 20 Apr 2022 13:32:36 +0200 In-reply-to: <20211201181040.23337-6-alexei.starovoitov@gmail.com> Message-ID: <87sfq8f0ex.fsf@cloudflare.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Hi Alexei, On Wed, Dec 01, 2021 at 10:10 AM -08, Alexei Starovoitov wrote: > From: Alexei Starovoitov > > struct bpf_core_relo is generated by llvm and processed by libbpf. > It's a de-facto uapi. > With CO-RE in the kernel the struct bpf_core_relo becomes uapi de-jure. > Add an ability to pass a set of 'struct bpf_core_relo' to prog_load command > and let the kernel perform CO-RE relocations. > > Note the struct bpf_line_info and struct bpf_func_info have the same > layout when passed from LLVM to libbpf and from libbpf to the kernel > except "insn_off" fields means "byte offset" when LLVM generates it. > Then libbpf converts it to "insn index" to pass to the kernel. > The struct bpf_core_relo's "insn_off" field is always "byte offset". > > Acked-by: Andrii Nakryiko > Signed-off-by: Alexei Starovoitov > --- > include/linux/bpf.h | 8 ++++ > include/uapi/linux/bpf.h | 59 +++++++++++++++++++++++++- > kernel/bpf/btf.c | 6 +++ > kernel/bpf/syscall.c | 2 +- > kernel/bpf/verifier.c | 76 ++++++++++++++++++++++++++++++++++ > tools/include/uapi/linux/bpf.h | 59 +++++++++++++++++++++++++- > tools/lib/bpf/relo_core.h | 53 ------------------------ > 7 files changed, 207 insertions(+), 56 deletions(-) > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > index cad0829710be..8bbf08fbab66 100644 > --- a/include/linux/bpf.h > +++ b/include/linux/bpf.h > @@ -1732,6 +1732,14 @@ bool bpf_prog_has_kfunc_call(const struct bpf_prog *prog); > const struct btf_func_model * > bpf_jit_find_kfunc_model(const struct bpf_prog *prog, > const struct bpf_insn *insn); > +struct bpf_core_ctx { > + struct bpf_verifier_log *log; > + const struct btf *btf; > +}; > + > +int bpf_core_apply(struct bpf_core_ctx *ctx, const struct bpf_core_relo *relo, > + int relo_idx, void *insn); > + > #else /* !CONFIG_BPF_SYSCALL */ > static inline struct bpf_prog *bpf_prog_get(u32 ufd) > { > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index 9e66b1880020..c26871263f1f 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -1342,8 +1342,10 @@ union bpf_attr { > /* or valid module BTF object fd or 0 to attach to vmlinux */ > __u32 attach_btf_obj_fd; > }; > - __u32 :32; /* pad */ > + __u32 core_relo_cnt; /* number of bpf_core_relo */ > __aligned_u64 fd_array; /* array of FDs */ > + __aligned_u64 core_relos; > + __u32 core_relo_rec_size; /* sizeof(struct bpf_core_relo) */ > }; > > struct { /* anonymous struct used by BPF_OBJ_* commands */ I think I've spotted a breakage. Plugging the 4 byte hole with core_relo_cnt means that programs built against < v5.17 headers pass garbage as core_relo_cnt value. That in turn makes check_core_relo() fail with -EINVAL, which fails PROG_LOAD. [...]