From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mail.toke.dk (Postfix) with ESMTPS id 185389CD41B for ; Fri, 9 Dec 2022 01:07:45 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=TVs+tM/z DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670544464; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UnV9sHMygGeqceDB6oqgI6Lx3Hl0PuFE6k1V3XoJZrg=; b=TVs+tM/z496wcnVrvP5o6/IEwNQbXGXSO6xhqF1+NDg+zMNTVBRTjE1L+Fj606In8Ta0Pb ToVCv4Cydj2qDbdc+pmGwlFWvPoHEc7ESAE0YqbXqiqmy+1WIB/xHVbLMjq+MC1KI0JCv4 iRAF1PN1PbCUkjEwQhsrKiVVYpysxog= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-454-uZSCg4SjNSa_LROjO7o1kg-1; Thu, 08 Dec 2022 19:07:43 -0500 X-MC-Unique: uZSCg4SjNSa_LROjO7o1kg-1 Received: by mail-ed1-f72.google.com with SMTP id i2-20020a05640242c200b0046c66305ebaso387501edc.15 for ; Thu, 08 Dec 2022 16:07:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UnV9sHMygGeqceDB6oqgI6Lx3Hl0PuFE6k1V3XoJZrg=; b=YaNrTVsAeDKTbzdOWUgB35ZN7Az63QFHwkOyKWtelySx8YIkm2vQLs5T8Sro/C5JpK 5JO56OFEFieqQWMJi+658/1AvdB7VSLhzowvAj6z1R+OKPYMwmF8VM1OlkDdhWX2OQeW MNioUpH3BS6j84+dmFdUXnlIo2crc3Kz4WQqT1wSd0cjltE0NBCFNLwH/Tmmt+d/I4VQ OVAltJNybbSda0sZDs1tFIWvSwTd+Sp2VEFbldrSyIRG5q6bf2BJEUFrbSQxC3yW9+Nh j0RiimReCbqP9Xm5ltnveUycbvuAiIwHCF3PPDUViqgNEPwhr8WxMTtH23Tdh1bqip/U 6ETQ== X-Gm-Message-State: ANoB5pkoDa15+F+o3ay4mbesB+xmRic8v3b1llSWjNzyS8g9SIi0a70l qDNWg+rj5gV99Rowd9Eq9j5FSO9Vm6bGtUReqGZFDtXbA7vDARsd5F2efIl70AI1OnO97ZKrCyI A3Rf+bs2INgWQh2mI9Y+f X-Received: by 2002:a17:907:8a22:b0:7af:16b5:9af8 with SMTP id sc34-20020a1709078a2200b007af16b59af8mr4472663ejc.33.1670544461798; Thu, 08 Dec 2022 16:07:41 -0800 (PST) X-Google-Smtp-Source: AA0mqf4jxNWVpUDFqe+Y4asR9M7ckORo70cpv13tgtmDSLBwLKzO+sRaQhDNDbBSqyQ9hON3IMdxMQ== X-Received: by 2002:a17:907:8a22:b0:7af:16b5:9af8 with SMTP id sc34-20020a1709078a2200b007af16b59af8mr4472566ejc.33.1670544459873; Thu, 08 Dec 2022 16:07:39 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id k2-20020a170906680200b0077077c62cadsm10135739ejr.31.2022.12.08.16.07.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 16:07:38 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id A80B782E9C7; Fri, 9 Dec 2022 01:07:37 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Stanislav Fomichev In-Reply-To: References: <20221206024554.3826186-1-sdf@google.com> <20221206024554.3826186-4-sdf@google.com> <878rjhldv0.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 09 Dec 2022 01:07:37 +0100 Message-ID: <87zgbxjv7a.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: ZPGZRKWSJENJAPE4LHZY4QKPWN7U4WLK X-Message-ID-Hash: ZPGZRKWSJENJAPE4LHZY4QKPWN7U4WLK X-MailFrom: toke@redhat.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: 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 to >> 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 :) -Toke