From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25CFBCA77 for ; Wed, 26 Jul 2023 12:08:25 +0000 (UTC) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65D3E199C for ; Wed, 26 Jul 2023 05:08:24 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-52164adea19so8872516a12.1 for ; Wed, 26 Jul 2023 05:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690373303; x=1690978103; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=J8f8xfrf9CO1UwpWhwva0oZFFF0z+1JGQgE5+04wLko=; b=7JuuMn+MBz5hYgANnpD4bEvks7OS3SHktyfwoRDMJGaRJlR3i5MAAhEZmypTHWIyuU btCWNmq9Pv4hGz6MJnqT3RauPr/grcWGwTB97C6LgE8o9CtC2Y21vI9abDbmnyujE3B1 SKSpzgGkPEygRPQL2ui5iDwCvJf1pkbNHd6P3Id6TJx4JZNE7Nud8vnGeUaNqyo3JyCk /ZFQy6M1+WbOk/TQ3KyIHuXV9luoiFEHsx0HgDqJfy/DpzF+mOAcqlG9+LGe4B+F9Ibk /pdicgMTjiM1I4r4q0huPczbjkFjt6LeDFcFoxmPkfcH8Ae2whA8RGg8k3WF9greqpmJ SO6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690373303; x=1690978103; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=J8f8xfrf9CO1UwpWhwva0oZFFF0z+1JGQgE5+04wLko=; b=jGyjcZhFmB2kjIQPF0x74ZPhAtRFv8qEPee/FWGwwdf4XkrqIyljUDxi71IvjvEM9b xAAwyid1nmn0tkxyMg8q0Etq4XCXFGbX0yT27RPhzSG8YQr0x1eb7Y9py2tyqT1CqCmT otasTEZUOaLiLFln+Eueze6EZJ+V4kefo9oRptFLS1RAi3qf+oXfMsrSsJ9AJI6DIcM0 d0z+wua5R7g8ZGpDEGnt+2zG0bEh+YkObRx4+n34Z+epvpIky/yB1B1ljaTtbUhHCKyP YpM55uk1NHLcLXMPtX4T9pGT7B+rRwqpreHrQzfLVI4YuHZeCQGkv/fSfQ1RPFAsJReI nlww== X-Gm-Message-State: ABy/qLb8P7k2uzocbLIYZZ0wWMu4CGHuhQqa/Xu+zb2fKSylvlnzg9fM mQ5Z6kGxJYhj1RWzU+IxOQhmTg== X-Google-Smtp-Source: APBJJlFfOkPz2EQQoFKz5CJOLmVEaFKbVA+ian4eCyKk+BO4Er+9/WwSwumtYgFBv5QV1xjXsi5Nrg== X-Received: by 2002:a17:906:7690:b0:982:487c:7508 with SMTP id o16-20020a170906769000b00982487c7508mr1508512ejm.38.1690373302686; Wed, 26 Jul 2023 05:08:22 -0700 (PDT) Received: from google.com (107.187.32.34.bc.googleusercontent.com. [34.32.187.107]) by smtp.gmail.com with ESMTPSA id s8-20020a170906960800b0099316c56db9sm9438817ejx.127.2023.07.26.05.08.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jul 2023 05:08:22 -0700 (PDT) Date: Wed, 26 Jul 2023 12:08:17 +0000 From: Matt Bobrowski To: Alexei Starovoitov Cc: Andrii Nakryiko , Alexei Starovoitov , "David S. Miller" , Daniel Borkmann , Martin KaFai Lau , David Vernet , Dave Marchevsky , Tejun Heo , Kumar Kartikeya Dwivedi , Network Development , bpf , Kernel Team Subject: Re: [PATCH v2 bpf-next 0/4] bpf: Add detection of kfuncs. Message-ID: References: <20230317201920.62030-1-alexei.starovoitov@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,FSL_HELO_FAKE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Tue, Jul 25, 2023 at 02:00:40PM -0700, Alexei Starovoitov wrote: > On Tue, Jul 25, 2023 at 1:45 PM Matt Bobrowski wrote: > > > > Hey Alexei/Andrii, > > > > On Fri, Mar 17, 2023 at 01:19:16PM -0700, Alexei Starovoitov wrote: > > > From: Alexei Starovoitov > > > > > > Allow BPF programs detect at load time whether particular kfunc exists. > > > > So, I'm running a GCC built 6.3.7 Linux kernel and I'm attempting to > > detect whether a specific kfunc i.e. bpf_rcu_read_lock/unlock() exists > > using the bpf_ksym_exists() macro. However, I'm running into several > > BPF verifier constraints that I'm not entirely sure how to work around > > on the aforementioned Linux kernel version, and hence why I'm reaching > > out for some guidance. > > > > The first BPF verifier constraint that I'm running into is that prior > > to commit 58aa2afbb1e6 ("bpf: Allow ld_imm64 instruction to point to > > kfunc"), it seems that the ld_imm64 instruction with BPF_PSEUDO_BTF_ID > > can only hold a ksym address for the kind KIND_VAR. However, when > > attempting to use the kfuncs bpf_rcu_read_lock/unlock() from a BPF > > program, the kind associated with the BPF_PSEUDO_BTF_ID is actually > > KIND_FUNC, and therefore trips over this BPF verifier. > > > > The code within the example BPF program is along the lines of the > > following: > > ``` > > ... > > void bpf_rcu_read_lock(void) __ksym __weak; > > void bpf_rcu_read_unlock(void) __ksym __weak; > > ... > > if (bpf_ksym_exists(bpf_rcu_read_lock)) { > > bpf_rcu_read_lock(); > > } > > ... > > if (bpf_ksym_exists(bpf_rcu_read_unlock)) { > > bpf_rcu_read_unlock(); > > } > > ... > > ``` > > > > The BPF verifier error message that is generated on a 6.3.7 Linux > > kernel when attempting to load a BPF program that makes use of the > > above approach is as follows: > > * "pseudo btf_id {BTF_ID} in ldimm64 isn't KIND_VAR" > > > > The second BPF verifier constraint comes from attempting to work > > around the first BPF verifier constraint that I've mentioned > > above. This is trivially by dropping the conditionals that contain the > > bpf_ksym_exists() check and unconditionally calling the kfuncs > > bpf_rcu_read_lock/unlock(). > > > > The code within the example BPF program is along the lines of the > > following: > > ``` > > ... > > void bpf_rcu_read_lock(void) __ksym __weak; > > void bpf_rcu_read_unlock(void) __ksym __weak; > > ... > > bpf_rcu_read_lock(); > > ... > > bpf_rcu_read_unlock(); > > ... > > ``` > > > > However, in this case the BPF verifier error message that is generated > > on a 6.3.7 Linux kernel is as follows: > > * "no vmlinux btf rcu tag support for kfunc bpf_rcu_read_lock" > > > > This approach would be suboptimal anyway as the BPF program would fail > > to load on older Linux kernels complaining that the kfunc is > > referenced but couldn't be resolved. > > > > Having said this, what's the best way to resolve this on a 6.3.7 Linux > > kernel? The first BPF program I mentioned above making use of the > > bpf_ksym_exists() macro works on a 6.4 Linux kernel with commit > > 58aa2afbb1e6 ("bpf: Allow ld_imm64 instruction to point to kfunc") > > applied. Also, the first BPF program I mentioned above works on a > > 6.1.* Linux kernel... > > Backport of that commit to 6.3.x is probably the only way. Ah, that's very unfortunate. Should we consider sending this patch series to linux-stable so that it can be considered for 6.3.x? /M