Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp3593694pxb; Mon, 21 Feb 2022 01:17:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJweqzlsQlH9cEsBkYg52xD8/Bdit8GQ095FvQx8EeJageXpniko/FX0SUxZxGj/0jHQOgkc X-Received: by 2002:a17:902:aa05:b0:14d:66f5:3c3f with SMTP id be5-20020a170902aa0500b0014d66f53c3fmr17841825plb.157.1645435056821; Mon, 21 Feb 2022 01:17:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645435056; cv=none; d=google.com; s=arc-20160816; b=SA0GrzkgbbpkjIAtFsjdjHGO7XMpMn8pWNZec1S2E7J0vTm5RZG6JdLEOKj3lv3yL4 xWJlGB76nUysgA0FwGwlaBa7AHVJZVzU6kpqGkbvgAGiDcjc57FE/fMPKVhXEpbnHEdO 6ihCLSy5fm/ZgrBvNGQLDGHKATF8go9zH73luILk3As6BqVxC8Au+4V9Lkgf7evbpIEn jucmK4nQ3iYRnvwegKqQ1haQIvI36cf1UjsU6rvMj+0iqRuS/xLBqmyjnK9j9BJWXea/ /HZtCWgYVA7euvM1mB19T6gWB9GTm3sNpEudFm6G09TMBqA/Vn991QFT4kOk2vCYZPyK xxqA== 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=G9Q7iEOI+RLvtcakO5Iao1uloYl8oVzidfsHuxUslmg=; b=Fb2pWa9VdCQ8BNj9zR+pgCknwcGXy22RZoOKsQLKudhTUN6baSQYi3JxrCmfs525Fk pZUPFwgWoozLeEhp9XgD0PQ1cLo8o7tEmcIaHQtz5IOzHkRe1KclXh38Fi7DWOdH4Mqu ez5pc5l2DbbmNz29X+LqRIRpHtw07GA+ChRtesb2Tw694QWfOelZROZagHcEq+Xq2PdN FNTmr3BLidaVx3C4DpNR2/5fbMCyPEuIGDs/NchBjC5/pvQPuGe8Kc1v4YJz88Spk17f DehRq3VVLjoHiM7iBiv2ItTWrx3Fr+qnm1jLCmIgGj9j3a6bgl1kSl1Yr8j8+67YXLRz MFVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=e4uPllXx; 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 n17si7736958pfv.184.2022.02.21.01.17.13; Mon, 21 Feb 2022 01:17:36 -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=e4uPllXx; 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 S1345997AbiBUHSo (ORCPT + 99 others); Mon, 21 Feb 2022 02:18:44 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:51616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345941AbiBUHSh (ORCPT ); Mon, 21 Feb 2022 02:18:37 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C0282631; Sun, 20 Feb 2022 23:18:15 -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 dfw.source.kernel.org (Postfix) with ESMTPS id BE81860F31; Mon, 21 Feb 2022 07:18:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D93AEC340E9; Mon, 21 Feb 2022 07:18:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645427894; bh=LgQjXd4WN0kF4H55no28FnkGWNbYSD9+uIC761PMlbc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=e4uPllXxesVF8kZU6rixAvWBH7hkw5/x6qSlo1CxnP0B9Zt+wA+DFDrSlh2/9Zv57 BZrYiJZqlvm/yMNGLPYK4k2Wi0g4HcR3osWJn16gkcbc9Ra2xWgIG0xNIK1M2Ya04O Tv2BwVvv6XH+Azr/T2tlXdCsOnya7t5wpfpZlbR4LOqUDRAGWkCCB/qwji/0fzFz/n nFC6RKpk/LenLzQyx7jQWiK/kxIoAq6sftOzrzp9wZoYzKaoNOLQe38awRe4/87Z6l XJTXJwUAC/aWwrCVuKW5yiBf+iW6AszicZMXw58qW5+V01h2Msbi2hOJ2Sjs3OCyGk wssEgTVrgaMUw== Date: Mon, 21 Feb 2022 16:18:08 +0900 From: Masami Hiramatsu To: Alexei Starovoitov Cc: Andrii Nakryiko , Jiri Olsa , 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: <20220221161808.46d9809fed5be7be8e16e47d@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> <20220218130727.51db96861c3e1c79b45daafb@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.1 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 Fri, 18 Feb 2022 18:10:08 -0800 Alexei Starovoitov wrote: > 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? > > > > > > > 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/ > > Is this a way for user space to inject user bytes into kernel events? Yes, it is. > What is the use case? This is like trace_marker but more ftrace/perf friendly version. The trace_marker can only send a user string, and the kernel can not parse it. Thus, the traced data will be shown in the trace buffer, but the event filter, event trigger, histogram etc didn't work with trace_marker. On the other hand, the user-events allows user-space defines new events with various arguments with types, and the application can send the formatted raw data to the kernel. Thus the kernel can apply event filter, event trigger and histograms on those events as same as other kernel defined events. This will be helpful for users to push their own data as events of ftrace and perf (and eBPF I think) so that they can use those tracing tools to analyze both of their events and kernel events. :-) Thank you, -- Masami Hiramatsu