Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp15955imi; Wed, 20 Jul 2022 16:00:10 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tAkYXYDM8OgzDWbKmQZoxk22aIJ2DmjhypCdtHygZkcOEBWL0ktLIMR1jnu/FpH7EIYwVT X-Received: by 2002:a17:903:2052:b0:16d:2429:e001 with SMTP id q18-20020a170903205200b0016d2429e001mr4329211pla.20.1658358009992; Wed, 20 Jul 2022 16:00:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658358009; cv=none; d=google.com; s=arc-20160816; b=fKlQhekQoDY982gmwvq87cYW9ecQRjtiAG/KFIEXqNa4JP9tHtvlgy5Ma7RWH7xzOn 4koB1aGs42wzHFs3sAH6Z/232jduWW9Q4sH5vZF7ZbAmDVoRFNqsFt0dlN/5CABwwQ8N RknjnZVOpOyDRPDLgPtJlhGTyajaADkvLaLcKaEXh6PP9aGltZJQcgN48rNtcjJ0f7Gh 2QxwWECvNTCDHYYM/TmBrwB5OCxJBXfy1Oe1iHOs2/iTYh2OK3YLlGPsayGv5D+I5694 OtJrLBLSVBF4PkJNJstDD4yoaUogwJCFD0Oil6uDRTUzxikS7Oi43TKpWVy4Zgew2jYZ eUEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=YjOKIOAe42Eku6Sc+3/5eXJR9MOwocaou5xUqsAb5iU=; b=qVKXPzL65rA44ORqVrg7RoJfRBnL0MjgEWYcAtVrzTwxCq6efJmG+6usqQZg4c+NQ+ T0HRYrnRvc2HfgpHesHfk2RVI7BvExcCJGeIywLidj0HjmPzRMLmRvDdmsCoA+eQS/+S 72/QoXrCJuBMUId8mYb+kWZOenxLPwMJ9xJjRYWTTlG84nIxvwqw9EM8q/0/+KBkbQkn ir7t4F4V8WdAaBI6vW0bD92DZtbOfbPJge5oU2gA0cMOD7LbpZt/RUq1Cy0d9xO0Uorm HxCYktsQaVhP8QtUYst1G7V4zdUZRBBm2NNJAJwuYsUYIIioUrkOgJQ883HlBmgsmwNK iEEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=iIKPCfJ9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r130-20020a632b88000000b004152331e6a2si26420pgr.829.2022.07.20.15.59.54; Wed, 20 Jul 2022 16:00:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=iIKPCfJ9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230028AbiGTWsY (ORCPT + 99 others); Wed, 20 Jul 2022 18:48:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbiGTWsX (ORCPT ); Wed, 20 Jul 2022 18:48:23 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CBB230F55 for ; Wed, 20 Jul 2022 15:48:22 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id d7so131177plr.9 for ; Wed, 20 Jul 2022 15:48:22 -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=YjOKIOAe42Eku6Sc+3/5eXJR9MOwocaou5xUqsAb5iU=; b=iIKPCfJ9i1WXaplnf56feWtYmg3cpfTZC/qXXRhj9fEH58gK+V11Ly6oj10mhYlV21 5jQFnkEORCUS0bpNFhY38o8KU8fqxsqLlXeQUJPSMgVGNiVcvdohI75L+1a9HOA9UpKm BkO9G3rfg40i18YzNWuiE92Ct1DQ0zs4RHdQRqu4BInGIqOM4JL/mYzyL4MZr8xF+xvs 7Zdy1jJhNERtbBGF0N9bCVI83IK9+DpfxbagbnyQEMnDoFgfumBLL6DwmS/v2teVqGKa gsjm8fOP23aCIPKAXQ4uCjwmfk6HIBjrA46JuXOJTYUaeR8s6InSjC90AXukfsSjjCbu lZOg== 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=YjOKIOAe42Eku6Sc+3/5eXJR9MOwocaou5xUqsAb5iU=; b=ImxpnO81VUD5bF/qIVOA+sLqvqCnoI/JKCaPN/YxZFqWaJ/+Y17HJgCF+wV0i8DksW zh4NZY+/CVnZj0ROVAdwX/SgOi4KbWzJqSO9JKn434yBfW9V2ehGRCkr2KP+WrifLyPi 1VsrsTNhzbpm/otuXVpEH0slzWGrp/XWhHEu9mzBIG5iCrg34J9CYv5zoxP0hvuP04Hv 80JHTHq7fpaK9c0P7w+pYmfYBbu/8fDOF8D4vNfmy5qRvRjhs6379qZ0v6NJkyVqmB6K MYbPwrdygSTDO8mhZjd2ldV5IHIWC/4dg/xjN+1upTKgHUIc7nZDSEDv4Huq7YCbqFIG UzTQ== X-Gm-Message-State: AJIora9BXsn6Zu+dVTMW6RE+M7BvAOjP6dVQKRwl1kuV13C4IOHJUgIr PkJeJa9k48CgmF1Ij7Lzj9Ytei5PzUtKQvOMIi2NGg== X-Received: by 2002:a17:902:db11:b0:16c:3e90:12e5 with SMTP id m17-20020a170902db1100b0016c3e9012e5mr40407911plx.73.1658357301486; Wed, 20 Jul 2022 15:48:21 -0700 (PDT) MIME-Version: 1.0 References: <20220719194028.4180569-1-jevburton.kernel@gmail.com> <179cfb89be0e4f928a55d049fe62aa9e@huawei.com> <31473ddf364f4f16becfd5cd4b9cd7d2@huawei.com> <0c284e09817e4e699aa448aa25af5d79@huawei.com> In-Reply-To: <0c284e09817e4e699aa448aa25af5d79@huawei.com> From: Stanislav Fomichev Date: Wed, 20 Jul 2022 15:48:10 -0700 Message-ID: Subject: Re: [PATCH v2 bpf-next] libbpf: Add bpf_obj_get_opts() To: Roberto Sassu Cc: Joe Burton , Andrii Nakryiko , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , "bpf@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Joe Burton Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 20, 2022 at 3:44 PM Roberto Sassu wrote: > > > From: Stanislav Fomichev [mailto:sdf@google.com] > > Sent: Thursday, July 21, 2022 12:38 AM > > On Wed, Jul 20, 2022 at 3:30 PM Roberto Sassu > > wrote: > > > > > > > From: Stanislav Fomichev [mailto:sdf@google.com] > > > > Sent: Wednesday, July 20, 2022 5:57 PM > > > > On Wed, Jul 20, 2022 at 1:02 AM Roberto Sassu > > > > > > wrote: > > > > > > > > > > > From: Stanislav Fomichev [mailto:sdf@google.com] > > > > > > Sent: Tuesday, July 19, 2022 10:40 PM > > > > > > On Tue, Jul 19, 2022 at 12:40 PM Joe Burton > > > > > > > > wrote: > > > > > > > > > > > > > > From: Joe Burton > > > > > > > > > > > > > > Add an extensible variant of bpf_obj_get() capable of setting the > > > > > > > `file_flags` parameter. > > > > > > > > > > > > > > This parameter is needed to enable unprivileged access to BPF maps. > > > > > > > Without a method like this, users must manually make the syscall. > > > > > > > > > > > > > > Signed-off-by: Joe Burton > > > > > > > > > > > > Reviewed-by: Stanislav Fomichev > > > > > > > > > > > > For context: > > > > > > We've found this out while we were trying to add support for unpriv > > > > > > processes to open pinned r-x maps. > > > > > > Maybe this deserves a test as well? Not sure. > > > > > > > > > > Hi Stanislav, Joe > > > > > > > > > > I noticed now this patch. I'm doing a broader work to add opts > > > > > to bpf_*_get_fd_by_id(). I also adjusted permissions of bpftool > > > > > depending on the operation type (e.g. show, dump: BPF_F_RDONLY). > > > > > > > > > > Will send it soon (I'm trying to solve an issue with the CI, where > > > > > libbfd is not available in the VM doing actual tests). > > > > > > > > Is something like this patch included in your series as well? Can you > > > > use this new interface or do you need something different? > > > > > > It is very similar. Except that I called it bpf_get_fd_opts, as it > > > is shared with the bpf_*_get_fd_by_id() functions. The member > > > name is just flags, plus an extra u32 for alignment. > > > > We can bikeshed the naming, but we've been using existing conventions > > where opts fields match syscall fields, that seems like a sensible > > thing to do? > > The only problem is that bpf_*_get_fd_by_id() functions would > set the open_flags member of bpf_attr. > > Flags would be good for both, even if not exact. Believe me, > duplicating the opts would just create more confusion. Wait, that's completely different, right? We are talking here about BPF_OBJ_GET (which has related BPF_OBJ_PIN). Your GET_XXX_BY_ID are different so you'll still have to have another wrapper with opts? > > > It needs to be shared, as there are functions in bpftool calling > > > both. Since the meaning of flags is the same, seems ok sharing. > > > > So I guess there are no objections to the current patch? If it gets > > accepted, you should be able to drop some of your code and use this > > new bpf_obj_get_opts.. > > If you use a name good also for bpf_*_get_fd_by_id() and flags > as structure member name, that would be ok. > > Roberto > > > > Roberto > > > > > > > > Roberto > > > > > > > > > > > > --- > > > > > > > tools/lib/bpf/bpf.c | 10 ++++++++++ > > > > > > > tools/lib/bpf/bpf.h | 9 +++++++++ > > > > > > > tools/lib/bpf/libbpf.map | 1 + > > > > > > > 3 files changed, 20 insertions(+) > > > > > > > > > > > > > > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c > > > > > > > index 5eb0df90eb2b..5acb0e8bd13c 100644 > > > > > > > --- a/tools/lib/bpf/bpf.c > > > > > > > +++ b/tools/lib/bpf/bpf.c > > > > > > > @@ -578,12 +578,22 @@ int bpf_obj_pin(int fd, const char > > *pathname) > > > > > > > } > > > > > > > > > > > > > > int bpf_obj_get(const char *pathname) > > > > > > > +{ > > > > > > > + LIBBPF_OPTS(bpf_obj_get_opts, opts); > > > > > > > + return bpf_obj_get_opts(pathname, &opts); > > > > > > > +} > > > > > > > + > > > > > > > +int bpf_obj_get_opts(const char *pathname, const struct > > > > bpf_obj_get_opts > > > > > > *opts) > > > > > > > { > > > > > > > union bpf_attr attr; > > > > > > > int fd; > > > > > > > > > > > > > > + if (!OPTS_VALID(opts, bpf_obj_get_opts)) > > > > > > > + return libbpf_err(-EINVAL); > > > > > > > + > > > > > > > memset(&attr, 0, sizeof(attr)); > > > > > > > attr.pathname = ptr_to_u64((void *)pathname); > > > > > > > + attr.file_flags = OPTS_GET(opts, file_flags, 0); > > > > > > > > > > > > > > fd = sys_bpf_fd(BPF_OBJ_GET, &attr, sizeof(attr)); > > > > > > > return libbpf_err_errno(fd); > > > > > > > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h > > > > > > > index 88a7cc4bd76f..f31b493b5f9a 100644 > > > > > > > --- a/tools/lib/bpf/bpf.h > > > > > > > +++ b/tools/lib/bpf/bpf.h > > > > > > > @@ -270,8 +270,17 @@ LIBBPF_API int bpf_map_update_batch(int fd, > > > > const > > > > > > void *keys, const void *values > > > > > > > __u32 *count, > > > > > > > const struct bpf_map_batch_opts *opts); > > > > > > > > > > > > > > +struct bpf_obj_get_opts { > > > > > > > + size_t sz; /* size of this struct for forward/backward compatibility > > */ > > > > > > > + > > > > > > > + __u32 file_flags; > > > > > > > +}; > > > > > > > +#define bpf_obj_get_opts__last_field file_flags > > > > > > > + > > > > > > > LIBBPF_API int bpf_obj_pin(int fd, const char *pathname); > > > > > > > LIBBPF_API int bpf_obj_get(const char *pathname); > > > > > > > +LIBBPF_API int bpf_obj_get_opts(const char *pathname, > > > > > > > + const struct bpf_obj_get_opts *opts); > > > > > > > > > > > > > > struct bpf_prog_attach_opts { > > > > > > > size_t sz; /* size of this struct for forward/backward compatibility > > */ > > > > > > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map > > > > > > > index 0625adb9e888..119e6e1ea7f1 100644 > > > > > > > --- a/tools/lib/bpf/libbpf.map > > > > > > > +++ b/tools/lib/bpf/libbpf.map > > > > > > > @@ -355,6 +355,7 @@ LIBBPF_0.8.0 { > > > > > > > > > > > > > > LIBBPF_1.0.0 { > > > > > > > global: > > > > > > > + bpf_obj_get_opts; > > > > > > > bpf_prog_query_opts; > > > > > > > bpf_program__attach_ksyscall; > > > > > > > btf__add_enum64; > > > > > > > -- > > > > > > > 2.37.0.170.g444d1eabd0-goog > > > > > > >