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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01077C433EF for ; Sat, 25 Sep 2021 00:31:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C9F2761212 for ; Sat, 25 Sep 2021 00:31:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232673AbhIYAce (ORCPT ); Fri, 24 Sep 2021 20:32:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233267AbhIYAcc (ORCPT ); Fri, 24 Sep 2021 20:32:32 -0400 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD2F2C061571; Fri, 24 Sep 2021 17:30:58 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id r4so9395441ybp.4; Fri, 24 Sep 2021 17:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XTIT3DcDFj/D+7v/Md+zN3ePNaIce3cNTgFNX/N3AOU=; b=iyay8woXD748wpwbDvwdFJ2t8R87psS04WMV6wZ2iB8x+q8XMTYLvVs+z+hEj9TwEt WElZaXOh6CU67l86H4nlww/hvcBDmX6i+Q+l1fQiRzkMMCj3EshvwAIItsQz/GshXQgM pkA7Hu0+6p9KC5KVYi1OSQogdER5Wvrr38tirC8BsH8JlaIzhpGi8qj+P0Yv9F0NgYzZ wYlHlwV8Fp9Bkf2q479gMWSwx4nREiq/jEguV9Z/xMS7EqndSwngPCtcFdXyHf3+R1xF CEXtR0JPeEMDZ9IrA37C6xt/EaQKs3RI6QBiAMRAQB2ZXodisaMB1IzW+uRpV2AN29gB DduQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XTIT3DcDFj/D+7v/Md+zN3ePNaIce3cNTgFNX/N3AOU=; b=bNAFtU8nDqycZE4+yN2Jn1KM2ZwoFV8zUA8HvwLLn5mC68DiYXPZNQgAPO2pdHAi1Z N+EEYgN+O7BfyqDmkaqfkdnnu128kbZ6rpVaWz7Lp/K5FtZGlhAhK3NqLVV6Hdj5Mypk UUaYLjIzcP7P5HxgPfnV0oxOuUAkSMOQfOBqIQq1Y262Qb35yAiiqJhBPTEH0VhrB2cE l/Sv2x+HWsVQEH4VZ6zxpLq/AjYVWfWhPrUEScv7JKkgLR9xynxsXE/gZjXjNbx70YpM oDqNamke+aigEvKa7Y8FKxrUukM+r+7OaHN6pVKDsHB8hfnEGBroZgXmxjPQSs2hS7i+ aS/A== X-Gm-Message-State: AOAM533lBsHNdfxCNp90vAOkMaZnGxx88cOUb5oCC9ArcWwDi76Mc44k sIhfxP56hToGvNvZAK/kGS6N+1HJw52T48zDFoA= X-Google-Smtp-Source: ABdhPJxCrm3O6ya6Ol31/WqjQ1liykKg7+y+pcBuiAClWEcmzn7Wr3Eb07VWF1u1qzAk2ZGrco96A8PSq5TwFuJdbWU= X-Received: by 2002:a05:6902:724:: with SMTP id l4mr15247970ybt.433.1632529857216; Fri, 24 Sep 2021 17:30:57 -0700 (PDT) MIME-Version: 1.0 References: <20210920141526.3940002-1-memxor@gmail.com> <20210920141526.3940002-7-memxor@gmail.com> <20210924235417.eqhzbrajwkenk6rd@apollo.localdomain> In-Reply-To: <20210924235417.eqhzbrajwkenk6rd@apollo.localdomain> From: Andrii Nakryiko Date: Fri, 24 Sep 2021 17:30:46 -0700 Message-ID: Subject: Re: [PATCH bpf-next v4 06/11] libbpf: Support kernel module function calls To: Kumar Kartikeya Dwivedi Cc: bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , Jesper Dangaard Brouer , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Networking Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, Sep 24, 2021 at 4:54 PM Kumar Kartikeya Dwivedi wrote: > > On Wed, Sep 22, 2021 at 04:11:13AM IST, Andrii Nakryiko wrote: > > On Mon, Sep 20, 2021 at 7:15 AM Kumar Kartikeya Dwivedi > > wrote: > > > [...] > > > + return -E2BIG; > > > + } > > > + ext->ksym.offset = index; > > > > > + } else { > > > + ext->ksym.offset = 0; > > > } > > > > I think it will be cleaner if you move the entire offset determination > > logic after all the other checks are performed and ext is mostly > > populated. That will also make the logic shorter and simpler because > > if ayou find kern_btf_fd match, you can exit early (or probably rather > > Ack to everything else (including the other mail), but... > > > goto to report the match and exit). Otherwise > > > > This sentence got eaten up. No idea what I was going to say here, sorry... Sometimes Gmail UI glitches with undo/redo, maybe that's what happened here. Doesn't matter, ignore the "Otherwise" part. > > > > > > > kern_func = btf__type_by_id(kern_btf, kfunc_id); > > > > this is actually extremely wasteful for module BTFs. Let's add > > internal (at least for now) helper that will search only for "own" BTF > > types in the BTF, skipping types in base BTF. Something like > > btf_type_by_id_own()? > > > > Just to make sure I am not misunderstanding: I don't see where this is wasteful. > btf_type_by_id seems to not be searching anything, but just returns pointer in > base BTF if kfunc_id < btf->start_id, otherwise in module BTF. > Hm, sorry... Right sentiment and thought, but wrong piece of code to quote it on. I had in mind the btf__find_by_name_kind() use in find_ksym_btf_id(). Once we start going over each module, we shouldn't be re-checking vmlinux BTF when doing btf__find_by_name_kind. It should only check the types that each module BTF adds on top of vmlinux BTF. That's what would be good to optimize, especially as more complicated BPF programs will start using more ksym vars and funcs. > What am I missing? I guess the 'kern_btf' name was the source of confusion? If > so, I'll rename it. > > Thanks. > > -- > Kartikeya