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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00BAEC2BA1A for ; Tue, 7 Apr 2020 17:34:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C33FC2078C for ; Tue, 7 Apr 2020 17:34:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Hddv0C4k" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726332AbgDGRe2 (ORCPT ); Tue, 7 Apr 2020 13:34:28 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:35282 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726277AbgDGRe2 (ORCPT ); Tue, 7 Apr 2020 13:34:28 -0400 Received: by mail-pf1-f194.google.com with SMTP id a13so1125640pfa.2; Tue, 07 Apr 2020 10:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VfOmombnx46eshTSKRK9pRfZX76vCXDPnZXls0b51W4=; b=Hddv0C4kDCfZnk2aC1nGmIdqB+XhZGb5+u8cg0skh3IhZHszlQML6SsJmVOEPvlzC3 cvG9y9qFXCjYTfuFZ4yHxHFZ0F0DUaJ2HKJUaVMabXAKfm3iOJLjjtr+Oo8eo5GFPn9F 5bg8QwvETywP8lpmMV9Mx5UMk20o+ehbDlCIWALsBQzksEO9mP9GCkWK5SoKsYht2Nqo muzRNQFCLmTZP6rmVDo0FO9BsUb+PPVYF8kwWycdAEkm5c3ASxYS7m0A1KnWM7bnwgXN s2NinSYKFQ1iHmZQwQxOfBPVfIL+ZJf/yiGP/SDZZHuC839oDrSeCSdFEPLaDUikmy8W wHaQ== 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=VfOmombnx46eshTSKRK9pRfZX76vCXDPnZXls0b51W4=; b=XpGrK5CTOWbNxaNHXushRxdUs/WWzunt1DqV4HKokUnz3cDVd7BUUKxNZokdtbu2xu pllq4sYOje7luj4KELBy2/gniPfxfHNvNcSTG9q9LrzQqOYqCRcyfQ0rDQh1VXXPVoXu LO6esU65RCmusn/d6dOoDiF/2KdHXuLD2g4pkU73ZXRvCkQZBL0RKV9J8eMTrpQiYMQt /3XLrf8XmAAquSfWJsTB5NCwAlRyDhTIr92Ghcqtud9ehS1irbox+nkzfba8CE1pRe2o MrGMknxdmaZr1MHs7PCCuNOl9ZKmns1NlmwYggsDc2kexkzxXUAhJH8yYgTtFfzNqhCg ZqrQ== X-Gm-Message-State: AGi0PuYCdF35AJm/Ba8FteXn7p3W3w8RDMNnT+9FMCa3rG9Qdkx7iPmp wdOMC7dckHeavtqJZw2Bowaax2b1 X-Google-Smtp-Source: APiQypIa74zR0qmYTbKig2FWmaxACiZBiwVwKrRADP9Gpene7wmvTJ8v7M8WNDzgMsj7vfTCmBl1pg== X-Received: by 2002:a63:741b:: with SMTP id p27mr3114156pgc.68.1586280866998; Tue, 07 Apr 2020 10:34:26 -0700 (PDT) Received: from ast-mbp.dhcp.thefacebook.com ([2620:10d:c090:400::5:863d]) by smtp.gmail.com with ESMTPSA id x68sm13108858pfb.5.2020.04.07.10.34.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 10:34:25 -0700 (PDT) Date: Tue, 7 Apr 2020 10:34:23 -0700 From: Alexei Starovoitov To: Matt Cover Cc: Daniel Borkmann , "David S. Miller" , Matthew Cover , netdev , bpf , kernel-team@fb.com Subject: Re: unstable bpf helpers proposal. Was: [PATCH bpf-next v2 1/2] bpf: add bpf_ct_lookup_{tcp,udp}() helpers Message-ID: <20200407173423.jh2ed3enaohfo5g2@ast-mbp.dhcp.thefacebook.com> References: <20200121202038.26490-1-matthew.cover@stackpath.com> <20200130215330.f3unziderf5rlipf@ast-mbp> <20200220044505.bpfvdrcmc27ik2jp@ast-mbp> <20200407030303.ffs7xxruuktss5fs@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, Apr 06, 2020 at 10:28:13PM -0700, Matt Cover wrote: > > > > I don't see why 1 and 2 are necessary. > > What is the value of true export_symbol here? > > Hmm... I was under the impression that these functions had to be > exported to be eligible for BTF. Perhaps I'm misunderstanding this > dwaves commit: > > 3c5f2a224aa1 ("btf_encoder: Preserve and encode exported functions > as BTF_KIND_FUNC") > > Looking briefly I can see that the functions in symvers and BTF are > not an exact match. Does "exported functions" in the above commit > message not mean "exported symbols"? Yeah. That pahole's commit log is confusing. It meant to say that all of exported symbols will be in BTF along with all other global functions. $ bpftool btf dump file ./bld_x64/vmlinux|grep __icmp_send [71784] FUNC '__icmp_send' type_id=71783 $ bpftool btf dump file ./bld_x64/vmlinux|grep bpf_prog_alloc_no_stats [17945] FUNC 'bpf_prog_alloc_no_stats' type_id=17943 First one is exported. Second is a simple global. There is no difference between them from BTF pov. pahole can be improved too. If it turns out that certain static functions has to be in BTF we can easily make it so. > > > > crc don't add any additional value on top of BTF. BTF types has to match exactly. > > It's like C compiler checking that you can call a function with correct proto. > > I can see that for the verifier BTF is much superior to crc. The > safety of the program is not improved by the crc. I was simply > thinking the crc could be used in struct variant selection instead > of kernel version. In some environments this could be useful since > distros often backport patches while leaving version old (often > meaning a second distro-specific version must also be considered). The kernel version should not be used in any kind of logic. Lots of folks backport bpf patches to older versions of the kernel. The kernel version is meaningless form bpf pov. We even removed kernel_version check from kprobe programs, because it was useless. vmlinux BTF is a complete description of the running kernel. It's the one that the verifier is using to do it safety checks.