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 0F86CC433FE for ; Tue, 22 Feb 2022 12:42:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232002AbiBVMnA (ORCPT ); Tue, 22 Feb 2022 07:43:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231993AbiBVMm4 (ORCPT ); Tue, 22 Feb 2022 07:42:56 -0500 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C9FC122216; Tue, 22 Feb 2022 04:42:31 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id u18so36620008edt.6; Tue, 22 Feb 2022 04:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sZOLEDaGh1SF5st8EQEk8EIqOeyAcu0epbvUe7EMQfA=; b=CtrlfUHtFIlffb9GrntCIKuLT7AfygnrZ9E5h3v2+48NWGW4ICXVWoOLZQHj1qffo9 NqmIXx3Mx/vKWRVk128yFnu44Mvpou1nrNMGLgffaVKOKS0Jr/eT89S2vyjmMzq27vzl /AUi1eYf8/8DperuLUE9ujZRdAqXWsNpLztjUcdVebtEZj1PWaMIgtBuZPBrlpSDn+XI /AJUQN2/hDlYrF/BJT+VUIqW8wHeOQxF02Xn572Dui+NodPgR4hlH2aiGwwo08lwcB2X ANlHFqZ6FNXzoXYiZZsNuZgQwSywEwkdh4kuEVfKVO2QgaoNop+eYCIbArP3vod/QkhT 2W3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sZOLEDaGh1SF5st8EQEk8EIqOeyAcu0epbvUe7EMQfA=; b=eL3k29rCvoA4ymi+bQSEtcCJk1vgwozQmNtPBrBfjjk9XhiQa6NIzLvDFkZe/n6jb6 CNhuhckUzdyI6l1AGXZb0VUDmapGmZiQJNwdsSxFYvbOvOdfspdMIuoOQGuixo0WEaWe zu1LFVfTNbPM2/DBU/nGmq0NcAq1gOnL8j0DvnviWi9+jDlGiP3pxiEOfMdOccE+OenJ 5EclWcDsvwhcOyI/EN4TsmhwmxuuDOR99rG6Xncx4jcyJHQ0YVp1hNcsBywnarqY4qM4 8zVrSEkXUSR7BXxvfnlkLMd5RA5EqPYco+VBc3F6t6RWwBrgKHRx2yKJtqxzrmgsB4cl jU3w== X-Gm-Message-State: AOAM531Uh7bKbuMoJYCi9jpxIXMK4NigE3cuKGwh3WwDeSKOgQ6bHH/r bJSgH8K4fVuwOxjGfM+sPiU= X-Google-Smtp-Source: ABdhPJxlzd38Mt5rRXYGTndmCY97WTXfiKT01qrwU2HkDalGwQg9uM1GFn1icvDOOboroyLwMZt0Zw== X-Received: by 2002:a50:9b12:0:b0:410:b926:d2d3 with SMTP id o18-20020a509b12000000b00410b926d2d3mr26282285edi.331.1645533749972; Tue, 22 Feb 2022 04:42:29 -0800 (PST) Received: from krava ([83.240.63.118]) by smtp.gmail.com with ESMTPSA id bn15sm6301853ejb.93.2022.02.22.04.42.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Feb 2022 04:42:29 -0800 (PST) Date: Tue, 22 Feb 2022 13:42:26 +0100 From: Jiri Olsa To: Andrii Nakryiko Cc: Masami Hiramatsu , 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 Subject: Re: [PATCH 0/8] bpf: Add fprobe link Message-ID: References: <20220204094619.2784e00c0b7359356458ca57@kernel.org> <20220204110704.7c6eaf43ff9c8f5fe9bf3179@kernel.org> <20220203211954.67c20cd3@gandalf.local.home> <20220204125942.a4bda408f536c2e3248955e1@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 16, 2022 at 10:27:19AM -0800, Andrii Nakryiko wrote: SNIP > > > > hi, > > tying to kick things further ;-) I was thinking about bpf side of this > > and we could use following interface: > > > > enum bpf_attach_type { > > ... > > BPF_TRACE_KPROBE_MULTI > > }; > > > > enum bpf_link_type { > > ... > > BPF_LINK_TYPE_KPROBE_MULTI > > }; > > > > union bpf_attr { > > > > struct { > > ... > > struct { > > __aligned_u64 syms; > > __aligned_u64 addrs; > > __aligned_u64 cookies; > > __u32 cnt; > > __u32 flags; > > } kprobe_multi; > > } link_create; > > } > > > > because from bpf user POV it's new link for attaching multiple kprobes > > and I agree new 'fprobe' type name in here brings more confusion, using > > kprobe_multi is straightforward > > > > thoguhts? > > I think this makes sense. We do need new type of link to store ip -> > cookie mapping anyways. > > 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? 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). > > 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. I need to check with uprobes, my understanding ends at perf/trace code calling uprobe_register ;-) maybe I should first try if uprobes suffer the same performance issue I'll send another version with above interface, because there's tons of other fixes, and by the time for next version we might have answer for the interface change jirka