From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by mail.toke.dk (Postfix) with ESMTPS id 6420C9CD5BB for ; Fri, 9 Dec 2022 03:57:44 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=UNuiPncl Received: by mail-pg1-x530.google.com with SMTP id r18so2646890pgr.12 for ; Thu, 08 Dec 2022 18:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V/coKp9zjVolqjPGhEWNOnNKzYKGenInUZCSrBAK7Js=; b=UNuiPncl/4ABZTPBsMCy21lPI0ozEf1DIzpIjE1GXMcF2d2ScJyC+GVuOrMYljfMyQ dFcb74GMeuSyyZhxt9HFZXSdEFGv7JqjxdmGwyvrA7EJxMr9fUeTi/7WQqnmBA/IvJm5 +SPinmoqtD2r5iNdzt+pP4EWpLy1A+6pHRF/iPX4BQRdFoewVVpoFyHjBR7C/YC7mAF/ xtrkxyWHT7h2gAxBsBaFuENJdUCpivIG6FIOfvRhiTxrhlG/0ezeRbJbEtP/VKWAXTdT yi4z+XvBs5Ucd/lPpM3v1Pw0vOOuz0Yc5FI+Kmr8brxHSeY1G4c3dZmMjxJVwVsfAvu3 W9Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V/coKp9zjVolqjPGhEWNOnNKzYKGenInUZCSrBAK7Js=; b=TV8MGlNvumjYXfrovtyoHlxvUdt2yf+59zZnnR5aYxfryJbN+12MbO137iMR0/s8Id J+3YdUIVyF0mb07RalLWMkKwhtrdyRWf2IsXaerNdBsBLoXc6tqjXZucMvtuROAbSrrU 6ygBV1d9akgx9wNa9/5bYlWc3bOyneXSaf7XXHfAppUEv40HN7jkkDVAwLKy/UQ9Yo4k 3AVuA50fvDKF8HScm2Pnki7UHYWRjm5wOwqpV90rxfe/qOKsTBMrR4AW0vGTd0rrZdjE vHDq0KB8UU5g4dWrngrcbAgcUc13UOvJA80yhyFKathBACxNP/PZE7+neliDp5tv53g2 tkqg== X-Gm-Message-State: ANoB5plrJDqZ8LnOKQQQCH66CTpcpvkxCY/k+kLqiiPvwQUhuOnm6g3G XSbLIG/ZKGeX69kozqO+4wyDiwCAXndBw3678VSXhw== X-Google-Smtp-Source: AA0mqf5B2Vx/YWatybv77hIV/HI/vXmQ6z8jU1ses4rarDwgiriBATr6FQaS2y4dwfTKLe2q7g2G0PRlWYP1FwAx20w= X-Received: by 2002:a63:1747:0:b0:478:1391:fd14 with SMTP id 7-20020a631747000000b004781391fd14mr46875607pgx.112.1670554662836; Thu, 08 Dec 2022 18:57:42 -0800 (PST) MIME-Version: 1.0 References: <20221206024554.3826186-1-sdf@google.com> <20221206024554.3826186-4-sdf@google.com> <878rjhldv0.fsf@toke.dk> <87zgbxjv7a.fsf@toke.dk> In-Reply-To: <87zgbxjv7a.fsf@toke.dk> From: Stanislav Fomichev Date: Thu, 8 Dec 2022 18:57:30 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 7BJYMODO5ETTSEUL36WQJ2HXOLD6MB4B X-Message-ID-Hash: 7BJYMODO5ETTSEUL36WQJ2HXOLD6MB4B X-MailFrom: sdf@google.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v3 03/12] bpf: XDP metadata RX kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Dec 8, 2022 at 4:07 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Stanislav Fomichev writes: > > >> Another UX thing I ran into is that libbpf will bail out if it can't > >> find the kfunc in the kernel vmlinux, even if the code calling the > >> function is behind an always-false if statement (which would be > >> eliminated as dead code from the verifier). This makes it a bit hard t= o > >> conditionally use them. Should libbpf just allow the load without > >> performing the relocation (and let the verifier worry about it), or > >> should we have a bpf_core_kfunc_exists() macro to use for checking? > >> Maybe both? > > > > I'm not sure how libbpf can allow the load without performing the > > relocation; maybe I'm missing something. > > IIUC, libbpf uses the kfunc name (from the relocation?) and replaces > > it with the kfunc id, right? > > Yeah, so if it can't find the kfunc in vmlinux, just write an id of 0. > This will trip the check at the top of fixup_kfunc_call() in the > verifier, but if the code is hidden behind an always-false branch (an > rodata variable set to zero, say) the instructions should get eliminated > before they reach that point. That way you can at least turn it off at > runtime (after having done some kind of feature detection) without > having to compile it out of your program entirely. > > > Having bpf_core_kfunc_exists would help, but this probably needs > > compiler work first to preserve some of the kfunc traces in vmlinux.h? > > I am not sure how the existing macros work, TBH. Hopefully someone else > can chime in :) +1 I think we need to poke Andrii as a follow up :-) > -Toke >