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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93093C4332F for ; Tue, 31 May 2022 23:08:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348618AbiEaXIw (ORCPT ); Tue, 31 May 2022 19:08:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229471AbiEaXIv (ORCPT ); Tue, 31 May 2022 19:08:51 -0400 Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E1805005A; Tue, 31 May 2022 16:08:50 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id e7so100450vkh.2; Tue, 31 May 2022 16:08:50 -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=Rng1DtEmjOfsc28R1+vQxmPpAFzote6MnieP84LTVVQ=; b=gFAoyg4B6makpShZ73D7TERoEA1EYdTmgfo7LpPLkgpagLr1QLMwerizw8LCbOVzSz 0z2JXJt7DYJnuaTelxmOk+nQoSvcYdfrmLTd7BqYaZJpKf2cXSo+SnuzL5kVlXrYkeNr 6CWGVphPxaELhXQT4FC2fEd9hW6WUMOTd2ta7fZja7BmT17vPj6EdEkhZ6xASzXYyNzS yGGUm4Nndqdpmcd4X3OLogC5ZluscHuSWaVFsTFEtUOpI8/KnMYhtJJr8cCIV9xFoOof iPx9KcqGqISnqxE/lzGpY3Zd/8jqM7WaAYZ8i6V/N7oGtVxFCCJfugtgNTZN/X8rEhUq sKlQ== 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=Rng1DtEmjOfsc28R1+vQxmPpAFzote6MnieP84LTVVQ=; b=ILirwEa5E7VCG2n5N5vBfxRwzJZ9S/ZwTC1xFbWmWi5f3kSTcH4dwaPBQOjcfNO+4p s9o56Gpcdx1fMqrQQrRONxKTexkFC++gFgqEQmza14RlHZ9anqtDocAyA+pzvD5Q5ivh o92yEf4yAHKmYrANUo6YTK/hzunWQz/LfJ2DRusKvKNvXwFAow99CZs4X6kCTtq4vZ7l SSNZoaj3pLbs7xrh2bkuOxk7GDZWUWU2fMx33IK84F3NhfbU//o+f1UTry6v60nwlLGX tSZ5o4c0p3D2WHQ1V9UjgSR1htaKqk34Ngodmpl4Rb7uwBufGQbgtUMi2TfDcnmmf0H3 KdnA== X-Gm-Message-State: AOAM531PT6QVNudU/fxY0jdUWv0GydgvgI3kSDmn6ictMp/fvg7SV7xt l1ZGwXRX2KRzxOVGnTVAQmVXQMnx4mon+PbRTp0= X-Google-Smtp-Source: ABdhPJyvnnIcS6OzwHtYKKLDib5TGZkpZxD9p4cY9NeY3TXW6B2yOO3cF4H4Lmbu8yr+F7boe1k0rmjK2IdiCmsRnhE= X-Received: by 2002:a1f:5907:0:b0:352:6327:926f with SMTP id n7-20020a1f5907000000b003526327926fmr23352593vkb.1.1654038529488; Tue, 31 May 2022 16:08:49 -0700 (PDT) MIME-Version: 1.0 References: <20220524175035.i2ltl7gcrp2sng5r@kafai-mbp> <20220525203935.xkjeb7qkfltjsfqc@kafai-mbp> <20220526000332.soaacn3n7bic3fq5@kafai-mbp> <20220526012330.dnicj2mrdlr4o6oo@kafai-mbp> In-Reply-To: From: Andrii Nakryiko Date: Tue, 31 May 2022 16:08:38 -0700 Message-ID: Subject: Re: [PATCH bpf-next v7 05/11] bpf: implement BPF_PROG_QUERY for BPF_LSM_CGROUP To: Stanislav Fomichev Cc: Martin KaFai Lau , Networking , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, May 25, 2022 at 7:50 PM Stanislav Fomichev wrote: > > On Wed, May 25, 2022 at 6:23 PM Martin KaFai Lau wrote: > > > > On Wed, May 25, 2022 at 05:03:40PM -0700, Martin KaFai Lau wrote: > > > > But the problem with going link-only is that I'd have to teach bpftool > > > > to use links for BPF_LSM_CGROUP and it brings a bunch of problems: > > > > * I'd have to pin those links somewhere to make them stick around > > > > * Those pin paths essentially become an API now because "detach" now > > > > depends on them? > > > > * (right now it automatically works with the legacy apis without any > > > > changes) > > > It is already the current API for all links (tracing, cgroup...). It goes > > > away (detach) with the process unless it is pinned. but yeah, it will > > > be a new exception in the "bpftool cgroup" subcommand only for > > > BPF_LSM_CGROUP. > > > > > > If it is an issue with your use case, may be going back to v6 that extends > > > the query bpf_attr with attach_btf_id and support both attach API ? > > [ hit sent too early... ] > > or extending the bpf_prog_info as you also mentioned in the earlier reply. > > It seems all have their ups and downs. > > I'm thinking on putting everything I need into bpf_prog_info and > exporting a list of attach_flags in prog_query (as it's done here in > v7 + add attach_btf_obj_id). > I'm a bit concerned with special casing bpf_lsm_cgroup even more if we > go with a link-only api :-( > I can definitely also put this info into bpf_link_info, but I'm not > sure what's Andrii's preference? I'm assuming he was suggesting to do > either bpf_prog_info or bpf_link_info, but not both? I don't care much, tbh. Whichever makes most sense to you.