Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp125120pxa; Tue, 4 Aug 2020 18:39:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYO1qxnCDZ+ufMtk9g4fi0FUJXQO9BKErRl1K96JfvqSfU6aXF/FUDPbc9sPLYSiod8mSc X-Received: by 2002:a17:906:a284:: with SMTP id i4mr981396ejz.490.1596591570036; Tue, 04 Aug 2020 18:39:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596591570; cv=none; d=google.com; s=arc-20160816; b=cdoCh280HS+P6oOc5fqQiDt3zK9kNk660xrEk5zZSVtZ/S3q5Pt2HpVjYPoiqc3Aiw UdM3GwUnC7YSrpEqklPwq2WHTt/K956TFH0WXp0ROoqjRsPC0vINEliqG3zpm7bVoUI/ Yj7XMaBXdXMTu4sceWStA8ZCgJhF2pF1GcIju1ef2KFPTVM8Ey5lRY1YdN4iwEfMX8sL gQT9MoTBiMSJaTCIOVXXNWhYaQAzayTKZl7ETjHfUSMx7jEJIfxdwnPWOgClutoDabJL tkBtOb3+ntJ2YFcIbfOd0hho9eEeq+6YxVRxrOLIkevLQrUBxdkAjC0cFTAX6j2udvPa qE7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6+uZyxND/e705z2BJrrSR+eq5E0rutVK6A3yMf2U9bQ=; b=btmdr5wtVi6MhDi4fyPGT5i8cI+HW4jAiM5mdI6v/7p0xGmJXOUDmKZjLR2leZzfy6 EL1B2SiPkcicnUIHpmCN93dkCedfnzaJt+SElpJGCu39FjQJc3kniMQfxceFRMV6Phh5 WxLz3CI7n7CbjJ68jPT08/KOLbdGAWMSoLGW1Sfa9keUv//Kjw+zy04PxLwmuWsto+vV kjDeN4KqxbyspiTrsg1y3UVM8cCX+gMIlPvB1jIRhy/JStc67jpI1dqtw+LSaZjZ/toQ C5lfEUOX3VCFEUi3zbsbo2Llx9HkBCq1DMUcAVhmZ31tJOiZNGbC+/lYuGpV+6fjPXVi fFqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=u1HcNS5D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c95si461473edf.304.2020.08.04.18.39.06; Tue, 04 Aug 2020 18:39:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=u1HcNS5D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726282AbgHEBil (ORCPT + 99 others); Tue, 4 Aug 2020 21:38:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbgHEBik (ORCPT ); Tue, 4 Aug 2020 21:38:40 -0400 Received: from mail-yb1-xb43.google.com (mail-yb1-xb43.google.com [IPv6:2607:f8b0:4864:20::b43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49C08C06174A; Tue, 4 Aug 2020 18:38:40 -0700 (PDT) Received: by mail-yb1-xb43.google.com with SMTP id a34so17928178ybj.9; Tue, 04 Aug 2020 18:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6+uZyxND/e705z2BJrrSR+eq5E0rutVK6A3yMf2U9bQ=; b=u1HcNS5DtJRxqEPRRW0jRw44uthXArp0ZH7gKgekC/Kst/wtNFlT9qRGNLQ50DiI+k FSTvNBckWjeeIECB8B4PP2zPTZykyWeaBGWg+EXrzOF1gHRHb+TZEfJIiyHQskDWN2q2 317QV2IVr++h0HqJLhyavIxc6UGRZnyOvo7Qm1DpsP6OTFTkqi/nRwOad5740h9t0Kgp ZPAguu8EkoVN6OBpjan02cmajgk4HZSqIyq6VYZrQ4qgglELW3XS6lGHHraR9bfJuYlH i6Pz1+SJjaU7OfkzpOb+rqq95F5WmMHMojDuUTDgkB+n+PNm43IYJz4fXEtU8lxNDLSV NhbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6+uZyxND/e705z2BJrrSR+eq5E0rutVK6A3yMf2U9bQ=; b=CoFSe9i0Shnq3B3tJ+ghajqFx4zcjEXPY0msAy/5QlMP08yoKnQ9Hg7IDQMAWeu4t4 c8SEKneh3yDFGOqT7ji3eLPjgyZzFVynqBqtXRD7qDViTV/qSR3QoYVFG+iTe4UCdBSi tJCkflqzgTnkcXLxpwnl4kLoy/7prZX2Fy/Xk1lYksEWxtTJpPgNWFslzpMuyhtBal9z V+EafOzePptcn32RujcG6yZ7tXUA2+aRYclT+UhP+6CK0xyFfVHAvhAHyKOkVbWjZnw3 ALxeUG7doFA2WrWzqW6bHnK0zbMEFR55FjHXUgxnjI6VPO3uXRjYn9Tn8uqYAJZQMNxw 6/dw== X-Gm-Message-State: AOAM533LlK4d9dOmgdPy/l7wTGmPkNjtkf/XUvPt8W+pj5l1IVlKa/XO o8G9Puhi3w69KPWuu6Q28AfJQPMvw56UcscNhuAeKw== X-Received: by 2002:a25:824a:: with SMTP id d10mr1370701ybn.260.1596591519526; Tue, 04 Aug 2020 18:38:39 -0700 (PDT) MIME-Version: 1.0 References: <20200801084721.1812607-1-songliubraving@fb.com> <20200801084721.1812607-3-songliubraving@fb.com> <9C1285C1-ECD6-46BD-BA95-3E9E81C00EF0@fb.com> In-Reply-To: <9C1285C1-ECD6-46BD-BA95-3E9E81C00EF0@fb.com> From: Andrii Nakryiko Date: Tue, 4 Aug 2020 18:38:28 -0700 Message-ID: Subject: Re: [PATCH bpf-next 2/5] libbpf: support BPF_PROG_TYPE_USER programs To: Song Liu Cc: open list , bpf , Networking , Alexei Starovoitov , Daniel Borkmann , Kernel Team , john fastabend , KP Singh , Jesper Dangaard Brouer , Daniel Xu Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 3, 2020 at 6:18 PM Song Liu wrote: > > > > > On Aug 2, 2020, at 6:40 PM, Andrii Nakryiko wrote: > > > > On Sat, Aug 1, 2020 at 1:50 AM Song Liu wrote: > >> > > [...] > > > > >> }; > >> > >> LIBBPF_API int bpf_prog_test_run_xattr(struct bpf_prog_test_run_attr *test_attr); > >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > >> index b9f11f854985b..9ce175a486214 100644 > >> --- a/tools/lib/bpf/libbpf.c > >> +++ b/tools/lib/bpf/libbpf.c > >> @@ -6922,6 +6922,7 @@ static const struct bpf_sec_def section_defs[] = { > >> BPF_PROG_SEC("lwt_out", BPF_PROG_TYPE_LWT_OUT), > >> BPF_PROG_SEC("lwt_xmit", BPF_PROG_TYPE_LWT_XMIT), > >> BPF_PROG_SEC("lwt_seg6local", BPF_PROG_TYPE_LWT_SEG6LOCAL), > >> + BPF_PROG_SEC("user", BPF_PROG_TYPE_USER), > > > > let's do "user/" for consistency with most other prog types (and nice > > separation between prog type and custom user name) > > About "user" vs. "user/", I still think "user" is better. > > Unlike kprobe and tracepoint, user prog doesn't use the part after "/". > This is similar to "perf_event" for BPF_PROG_TYPE_PERF_EVENT, "xdl" for > BPF_PROG_TYPE_XDP, etc. If we specify "user" here, "user/" and "user/xxx" > would also work. However, if we specify "user/" here, programs that used > "user" by accident will fail to load, with a message like: > > libbpf: failed to load program 'user' > > which is confusing. xdp, perf_event and a bunch of others don't enforce it, that's true, they are a bit of a legacy, unfortunately. But all the recent ones do, and we explicitly did that for xdp_dev/xdp_cpu, for instance. Specifying just "user" in the spec would allow something nonsensical like "userargh", for instance, due to this being treated as a prefix. There is no harm to require users to do "user/my_prog", though. Alternatively, we could introduce a new convention in the spec, something like "user?", which would accept either "user" or "user/something", but not "user/" nor "userblah". We can try that as well. > > Thanks, > Song > > [...] >