Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp977662pxb; Thu, 17 Feb 2022 20:21:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJzb79zDTexPAb5fn4ppRNlRx/iwIZOBW7oEM4OEEVXP5mS0lc1CI195IhMR/IYk0dSSYON6 X-Received: by 2002:a17:906:8299:b0:6cf:3847:284b with SMTP id h25-20020a170906829900b006cf3847284bmr4814307ejx.682.1645158072561; Thu, 17 Feb 2022 20:21:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645158072; cv=none; d=google.com; s=arc-20160816; b=eT6sq619aGdVQmP19PiKug9349mRoiz8UNEiooE1uWggj4CVOqXM9t59QlPO6PaIXY YH3R19IyCGDv3PVpEe5ToMQCv8JX9tDA5eYM+LSiHtN8iZHdYTaWISz+pzlJJWwEaUUJ uJtnjUVuXdWWyZoxfWdasn1350gr6xUEpvjOE/kJWwd+UrDt6lg2GdK6b7+GafUL8js2 ogZleyF/tQaLbL1tul98aG4w6/4pXdwLDrB9oJr7pS7TeR3NmUMNcREewmbtt0phnDOS fEWXkKnPi3Nt68m/gOJiFJJGeA8LU79zpEqLBkggMOWotRLyn2lCdrQICHOabmuEYx1m 20Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=kZ0zzxE1OIXqdRFP1A6B+kwAyhjyjZe0dVzuYJE0U7E=; b=vQS4my0It9Az4HAsdKG5DTw4yhf/erIUQtPnKd8X5uwrfIJSTpg5/Yf0V6K+jXKBRH 9piSlw2Uf049GpktvS17q/J2qrlFV78L4/pLkrAZ5yRENU3Bk+yPsMuVWt9CFD76mDcG EspduAfuh4jFvgntuaWlKbAgXv8tHz8J0jaWd5pfnHh8G68CCWJAa0eOkStA2ICd5Mmp Z1vQannNrthzUKp6dhNEy7yMbeZLFU87wP3a/zEe1cU/NyX6Pt3tQZHQPtVLy9swU+L8 p8Nx0xyJtWDdYisEKhr1djBsDEqAfqG28vYSo0YKEsMfvhcGkP54IAMaSSmCZ4Xk9/V0 a0KA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SoYk0T1z; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jg8si4091165ejc.480.2022.02.17.20.20.49; Thu, 17 Feb 2022 20:21:12 -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=@kernel.org header.s=k20201202 header.b=SoYk0T1z; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229688AbiBREHy (ORCPT + 99 others); Thu, 17 Feb 2022 23:07:54 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:37444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229457AbiBREHx (ORCPT ); Thu, 17 Feb 2022 23:07:53 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F07A66CA7A; Thu, 17 Feb 2022 20:07:36 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 82DA1B82555; Fri, 18 Feb 2022 04:07:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7893EC340E9; Fri, 18 Feb 2022 04:07:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645157254; bh=cYuuDOJYlJ0GA8aOQN1fPD9uNOqWl6U/+6PySPtBn0o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SoYk0T1zpZbx6ZtuRLZScyIA9v0u6JZ+kMkNOJpecXA18uq+UFY6HecKmegKW/+GE 4YH5+D2IEZVrljZMeBuwLzKhpRvWg+QcTVZeiA315E4i5ZdHDBcKT8G5hVGrwgpRlU FoE+YZku6KHYLbHU1hb88nbt/k5mqmSoqhOe7NAP5TTxbjSj5mmndNIyL+aXxOD5NZ aR/y70og5+rONPRaIZ9guGtMBUXS29YABJM4a1BTDbJVP2iFCBivl8MGaZ/s6caYEj wHMF41q0jPQ7CnzNOyFiFQYNKnaTEDpOsHzDqS1Y/XR4x7rp7uMYH8kiWjRhf0rO8R ILn6MNUyeuFyg== Date: Fri, 18 Feb 2022 13:07:27 +0900 From: Masami Hiramatsu To: Andrii Nakryiko 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 Subject: Re: [PATCH 0/8] bpf: Add fprobe link Message-Id: <20220218130727.51db96861c3e1c79b45daafb@kernel.org> In-Reply-To: References: <20220204094619.2784e00c0b7359356458ca57@kernel.org> <20220204110704.7c6eaf43ff9c8f5fe9bf3179@kernel.org> <20220203211954.67c20cd3@gandalf.local.home> <20220204125942.a4bda408f536c2e3248955e1@kernel.org> <20220217230357.67d09baa261346a985b029b6@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,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, 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? > > > 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/ Thank you, -- Masami Hiramatsu