Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp2011495pxb; Fri, 18 Feb 2022 23:08:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJzDvHYbfYDTDcKwEwCuypyDEhbIXSPksAcBuZn6D1AZejz7o2B+IHNz5tKvXutY8FvBqgAh X-Received: by 2002:a17:90a:5505:b0:1b8:ebd4:d602 with SMTP id b5-20020a17090a550500b001b8ebd4d602mr11797047pji.147.1645254518614; Fri, 18 Feb 2022 23:08:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645254518; cv=none; d=google.com; s=arc-20160816; b=Fxyold6Yo3Ul/prhHW1NiV3DluetR8LUBX8g8FklGr1/9JhSkkyTpYjg66D1LJi1ph Fru+hXTLcKXn/kyXCPBH6T161YHBDytmT33lVMiAN4KdSsFU84bgtU14wG8uYNYygbk2 95nfEyyVwxthiX1vWNYcGxpYcJ1Uo0G5r6ObMQ9YJSIT7CS0CcrRckYaDyyKJsKS/fBq xNwyNeaKnGzG8ydjABap6OypycaBvEaqsMcf/zzKdhug94sybGFTiB9Q3B32PR7HnoEC lZdSrrpOmsfAJGGhJpvY5C3gGzIbAVLzfiKjDe/INkJSH5wz3nrZAp7q3aymNUGDsMLe bDCQ== 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=NtZXoooqCDPAZYhZFj3ZqvMxpCYgOZsPpYOZ1vg41sE=; b=VfL6P8RBI4+U+58RJHU7PDXe7Nac5LU73WHW6pn/pFx/6I4M7v1K17U7FjUFroVm18 Ja0evExko+GmVaoqzrErAu/R0w3gpqPRXeHQOiQ0aurIXuP1EPiEd9BXaQDd0QngDzfH R4sHy4roa+k19QNyfybNo1oGaaJnDCFbgHTIxXSAwAncdhw40hDuZfCipqlh2gd4a6Bh vHyBFcviGFMqJiw2Xq+0hXENeWitn5iY/iLm4d7VPAqltLYYs3J04V7JPTDQ0TNQhUbo TZ7Nnm/fud0OfifhPn04ZGjYgGNgfo3ITlljSRUUTM/U+y3nx/SOQwp4Cg/Blzyjd1VV t9lQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=lCkf7ZGt; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 22si1454112pjb.121.2022.02.18.23.08.24; Fri, 18 Feb 2022 23:08:38 -0800 (PST) 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=@gmail.com header.s=20210112 header.b=lCkf7ZGt; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237820AbiBRTqb (ORCPT + 99 others); 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-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" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 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