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 F0FBCC433F5 for ; Fri, 18 Feb 2022 19:46:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237764AbiBRTqb (ORCPT ); Fri, 18 Feb 2022 14:46:31 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:36420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234826AbiBRTqa (ORCPT ); Fri, 18 Feb 2022 14:46:30 -0500 Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F7681A2E7A; Fri, 18 Feb 2022 11:46:13 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id d3so5451621ilr.10; Fri, 18 Feb 2022 11:46:13 -0800 (PST) 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=NtZXoooqCDPAZYhZFj3ZqvMxpCYgOZsPpYOZ1vg41sE=; b=lCkf7ZGtKl4Np1oR9fePi+RvDaHQVlc7uRgy5rqKFL13Mt7LLrSpoFMV15KhWxV/JB oOk8Vu2sk/5lq5mv5LLnP457jQJadCNn0FBhLvT46RqQprxsW5xXKj8VH7TKMay1LSMw d0eBXtTTyNFCMhItQBBvFJ9o1Kc6AbNHNKVkwuqHb59CDTWEo9dTS85DF/LWVtwLu8WN IXGVF1vjn4pvlotIq5hO+YTuQzZ7pRzwc1vFs6bGYpaj2ablRC8PE5NBNS6mBnigLpfg H8BcEbkiQNk+r9GaVehWaPYZUHsUtF2bwE0pgaJfJvqnLfXi6UrWLaX9tNgC+XKfRX0s VL2g== 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=NtZXoooqCDPAZYhZFj3ZqvMxpCYgOZsPpYOZ1vg41sE=; b=6o4t63gS4UCAjvFRiL+KzSpWI1AqGamVb4NhYSfiExsDRV9B57x+ecVrsfcgiRz+gM l9opKIkJUfFsg6DvWnKpK7N2H2PYIsNF+a8vijeKEbXMWFsCaZjRUbNxOkLl6U0xS9X2 iPhbBdILgTklEg5FK9MWZNCEEQPUErjAPcp8A2zsSHai1oiQJIcFuKlfflfi0kRGFc+3 xaM5a/PXNYnMblU4aj04V7Vb1rKu+rQ8SGprUZ0da41BrojLJgrhnfR8qKh/CTAss6C6 bQed0HaL3jzXDDPl8fI4HC8l04zB5iBah31tU8wxmECWnceQahSXharE1Zc4eaPbbrT1 74Hw== X-Gm-Message-State: AOAM5338bo3kaKz+SXTXzy+Vnzass3HSW+S+LwtxkLuACzj5txQBa86e BfbmjBzlXIhXHrWcMnghEj/rZod6eO36xT+51kY= X-Google-Smtp-Source: ABdhPJzINzjgFGOAayf7gdBfTBcKyugk8IUzTeyKMb+T3r0cZicwb7BndLSqLTd7hBa64N+q3DifFydJdtXKs3kaeIs= X-Received: by 2002:a92:d208:0:b0:2c1:1a3c:7b01 with SMTP id y8-20020a92d208000000b002c11a3c7b01mr6430392ily.71.1645213572928; Fri, 18 Feb 2022 11:46:12 -0800 (PST) MIME-Version: 1.0 References: <20220204094619.2784e00c0b7359356458ca57@kernel.org> <20220204110704.7c6eaf43ff9c8f5fe9bf3179@kernel.org> <20220203211954.67c20cd3@gandalf.local.home> <20220204125942.a4bda408f536c2e3248955e1@kernel.org> <20220217230357.67d09baa261346a985b029b6@kernel.org> <20220218130727.51db96861c3e1c79b45daafb@kernel.org> In-Reply-To: <20220218130727.51db96861c3e1c79b45daafb@kernel.org> From: Andrii Nakryiko Date: Fri, 18 Feb 2022 11:46:01 -0800 Message-ID: Subject: Re: [PATCH 0/8] bpf: Add fprobe link To: Masami Hiramatsu Cc: Jiri Olsa , Alexei Starovoitov , Steven Rostedt , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Network Development , bpf , lkml , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Oleg Nesterov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Feb 17, 2022 at 8:07 PM Masami Hiramatsu wrote: > > On Thu, 17 Feb 2022 14:01:30 -0800 > Andrii Nakryiko wrote: > > > > > > Is there any chance to support this fast multi-attach for uprobe? If > > > > yes, we might want to reuse the same link for both (so should we name > > > > it more generically? > > > > > > There is no interface to do that but also there is no limitation to > > > expand uprobes. For the kprobes, there are some limitations for the > > > function entry because it needs to share the space with ftrace. So > > > I introduced fprobe for easier to use. > > > > > > > on the other hand BPF program type for uprobe is > > > > BPF_PROG_TYPE_KPROBE anyway, so keeping it as "kprobe" also would be > > > > consistent with what we have today). > > > > > > Hmm, I'm not sure why BPF made such design choice... (Uprobe needs > > > the target program.) > > > > > > > We've been talking about sleepable uprobe programs, so we might need > > to add uprobe-specific program type, probably. But historically, from > > BPF point of view there was no difference between kprobe and uprobe > > programs (in terms of how they are run and what's available to them). > > From BPF point of view, it was just attaching BPF program to a > > perf_event. > > Got it, so that will reuse the uprobe_events in ftrace. But I think > the uprobe requires a "path" to the attached binary, how is it > specified? It's passed as a string to perf subsystem during perf_event_open() syscall. > > > > > But yeah, the main question is whether there is something preventing > > > > us from supporting multi-attach uprobe as well? It would be really > > > > great for USDT use case. > > > > > > Ah, for the USDT, it will be useful. But since now we will have "user-event" > > > which is faster than uprobes, we may be better to consider to use it. > > > > Any pointers? I'm not sure what "user-event" refers to. > > Here is the user-events series, which allows user program to define > raw dynamic events and it can write raw event data directly from > user space. > > https://lore.kernel.org/all/20220118204326.2169-1-beaub@linux.microsoft.com/ > Thanks for the link! I'll check it out. > Thank you, > > -- > Masami Hiramatsu