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 F0D93C433EF for ; Tue, 24 May 2022 02:15:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233233AbiEXCPd (ORCPT ); Mon, 23 May 2022 22:15:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233235AbiEXCPc (ORCPT ); Mon, 23 May 2022 22:15:32 -0400 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2E9C9CCBE for ; Mon, 23 May 2022 19:15:30 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id v191-20020a1cacc8000000b00397001398c0so582779wme.5 for ; Mon, 23 May 2022 19:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=muL8b64Pp6kaxWu77c45PCZ8HuHx5jG9bLj/hnhVeK0=; b=o+QbVLXkFDFeU2SlI1fmlEFB+6cGdQUULFVbbrD/mMrYTOOhHoeTi1iSjXz55xgkLx DZMAUuijVuwzj7VKG0kCsL8jVq6qwZvDPGavYs/KN/CGHKJfnO0REG3hhbhGqerW4b2K KgwUAlCBj1hgCQOGeqeqa9jLznFMVVDYtLJO8dNIRcZNNbtssoOydjEZSg2GXDwOb9Sx vGnEEZfYGqWdbdEsanRUGeFFhcnBa55JQ+St4HiIRzZcExsSoeRy1CtVcTgspVJFkY2W SPUR2LrCFss/I9MRcdyIIC0e+SoC2gt2S1vyuhKKdt+ULty/e4HfNqWzpfCJPWriCftk Fwsw== 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=muL8b64Pp6kaxWu77c45PCZ8HuHx5jG9bLj/hnhVeK0=; b=WrUOEo43E8CtCD1Vg6DSdZvSK3wW/C/TVQcH3/M49KrFxvZdvlTbW0BKCcVsP21oHI yALqqfP4ZFQ5aFjhz+k2YdcVOnbUlV56gml+e0tQ0fhF7gHZSMarihvTnXqW1DNE2P46 kUM0aks8dlZB7u3p0VdvicXCkDrWvJE9rsEWI9450v68oIXmLP5mXTBb2m4pzsblPiUx N5gl7CPNuqImDWCLkHOMTEZlBdbtQBqul/Zaa6izOUitMYEqqQuzQqeLCw4CBsySYVCf y0e2lCHjP//daaiRTjg8RCcMm5mckRPIMC9XMt4R7ezSPuz60MvjjHyX+q38gRh99mmL ditg== X-Gm-Message-State: AOAM531nC/BFghogneEb4X/SeQpOzSX4nFgHeFx9Eu34XiMMjNfqFsbX pXEehqS6THfUvnEsfZW+ACpdAshiRmjxkOrMYGHYacZkZBI= X-Google-Smtp-Source: ABdhPJwSDlj1ctjYz34tqFMzLjXYLaqIQTUEFNrObdQSTLyM1Qo9v3U3926jMfw/A7QHheI1badsVgTmT1dSHvyXPVI= X-Received: by 2002:a05:600c:a03:b0:395:bc75:61eb with SMTP id z3-20020a05600c0a0300b00395bc7561ebmr1607860wmp.46.1653358529160; Mon, 23 May 2022 19:15:29 -0700 (PDT) MIME-Version: 1.0 References: <20220518225531.558008-1-sdf@google.com> <20220518225531.558008-6-sdf@google.com> In-Reply-To: From: Stanislav Fomichev Date: Mon, 23 May 2022 19:15:17 -0700 Message-ID: Subject: Re: [PATCH bpf-next v7 05/11] bpf: implement BPF_PROG_QUERY for BPF_LSM_CGROUP To: Andrii Nakryiko Cc: 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 Mon, May 23, 2022 at 4:24 PM Andrii Nakryiko wrote: > > On Wed, May 18, 2022 at 3:55 PM Stanislav Fomichev wrote: > > > > We have two options: > > 1. Treat all BPF_LSM_CGROUP the same, regardless of attach_btf_id > > 2. Treat BPF_LSM_CGROUP+attach_btf_id as a separate hook point > > > > I was doing (2) in the original patch, but switching to (1) here: > > > > * bpf_prog_query returns all attached BPF_LSM_CGROUP programs > > regardless of attach_btf_id > > * attach_btf_id is exported via bpf_prog_info > > > > Signed-off-by: Stanislav Fomichev > > --- > > include/uapi/linux/bpf.h | 5 ++ > > kernel/bpf/cgroup.c | 103 +++++++++++++++++++++++++++------------ > > kernel/bpf/syscall.c | 4 +- > > 3 files changed, 81 insertions(+), 31 deletions(-) > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index b9d2d6de63a7..432fc5f49567 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -1432,6 +1432,7 @@ union bpf_attr { > > __u32 attach_flags; > > __aligned_u64 prog_ids; > > __u32 prog_cnt; > > + __aligned_u64 prog_attach_flags; /* output: per-program attach_flags */ > > } query; > > > > struct { /* anonymous struct used by BPF_RAW_TRACEPOINT_OPEN command */ > > @@ -5911,6 +5912,10 @@ struct bpf_prog_info { > > __u64 run_cnt; > > __u64 recursion_misses; > > __u32 verified_insns; > > + /* BTF ID of the function to attach to within BTF object identified > > + * by btf_id. > > + */ > > + __u32 attach_btf_func_id; > > it's called attach_btf_id for PROG_LOAD command, keep it consistently > named (and a bit more generic)? > > > } __attribute__((aligned(8))); > > > > struct bpf_map_info { > > [...] SG. Making it generic makes sense.