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 E9331C433F5 for ; Thu, 6 Jan 2022 08:41:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236825AbiAFIlx (ORCPT ); Thu, 6 Jan 2022 03:41:53 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:24666 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236793AbiAFIlw (ORCPT ); Thu, 6 Jan 2022 03:41:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641458511; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B6cO0By3xfU7a9n6TEUm5Q0O0rT0zqzS45h4TsZ5dLM=; b=Bl7gttkmQZHecyTqB0Nh6cJmBusFYbgq+Hm2PeN9Kv6s3bUXPqz6A/x75H1+d2MmyRom33 c3VCTKn647eoLrpzEphdTGutft0KAbKAk3+wA3BqZ8INmc0igwsMBA/xpMw8sxpT3fvA1T u137Ze9YnVCSjWDe0CnYxImy9ME/cpo= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-393-j3qihre0N5eM6wn0FIUM3g-1; Thu, 06 Jan 2022 03:41:50 -0500 X-MC-Unique: j3qihre0N5eM6wn0FIUM3g-1 Received: by mail-ed1-f70.google.com with SMTP id w6-20020a05640234c600b003f916e1b615so1407428edc.17 for ; Thu, 06 Jan 2022 00:41:50 -0800 (PST) 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=B6cO0By3xfU7a9n6TEUm5Q0O0rT0zqzS45h4TsZ5dLM=; b=HdM9nZ2O+wlOub6CPiq/lVODNFMkVQ+WCrRHmLd+JOdmhcqHkyD1ZtrcjjT6Swvb0e o+u2s1d6QhgdpqbAwUm1Dwz5ruyUQ7m2aGqasPEf2BmpffvRVRw0mEmTVoU9gNWufycI 5DxqmSQAb7VOyFl7Yl4AB2q64/x+3MAo5oETJLHJQqTGUCmL4+iNWYnM6XLidCDjkSrA 7tgQzSA+7OGJ2vHFJKOfQ9XojIVoBySq85UV4T2lIwCIdVPEIFWKE7BzUcVhHIl38Url m194H9hBP0yM2yXrF/z6Ka0UEYrL6vBwtZX1yDU3vmrjndp5nuLStv+hJ+j1Isxjo+IU WO+Q== X-Gm-Message-State: AOAM530x70ZmI9e9ChTlC7cZmVgFtrAcBLR/ZLuqAp4gJp9aSsMtF7dL ibfSNGknbljngyyIaSclcxmL6hofLmb+hK4xTmJ1PxWONLd+XwgS08fwo7V9UBZsdJWDV9a0+zC AhC0TWu5USzEH4UjGVAvpzZL7 X-Received: by 2002:a05:6402:b41:: with SMTP id bx1mr55483119edb.292.1641458509066; Thu, 06 Jan 2022 00:41:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJyQIYkJhAAbOd6J0hHVNMxZpM46ATJPB6IQAd2TD7n+qeYiIloSdNHNaqNQIwh69l8u33Z77A== X-Received: by 2002:a05:6402:b41:: with SMTP id bx1mr55483112edb.292.1641458508882; Thu, 06 Jan 2022 00:41:48 -0800 (PST) Received: from krava (nat-pool-brq-u.redhat.com. [213.175.37.12]) by smtp.gmail.com with ESMTPSA id q20sm479615edt.13.2022.01.06.00.41.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jan 2022 00:41:47 -0800 (PST) Date: Thu, 6 Jan 2022 09:41:46 +0100 From: Jiri Olsa To: Andrii Nakryiko Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Masami Hiramatsu , Networking , bpf , lkml , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Steven Rostedt , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" Subject: Re: [PATCH 08/13] bpf: Add kprobe link for attaching raw kprobes Message-ID: References: <20220104080943.113249-1-jolsa@kernel.org> <20220104080943.113249-9-jolsa@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, Jan 05, 2022 at 08:30:56PM -0800, Andrii Nakryiko wrote: > On Tue, Jan 4, 2022 at 12:10 AM Jiri Olsa wrote: > > > > Adding new link type BPF_LINK_TYPE_KPROBE to attach kprobes > > directly through register_kprobe/kretprobe API. > > > > Adding new attach type BPF_TRACE_RAW_KPROBE that enables > > such link for kprobe program. > > > > The new link allows to create multiple kprobes link by using > > new link_create interface: > > > > struct { > > __aligned_u64 addrs; > > __u32 cnt; > > __u64 bpf_cookie; > > I'm afraid bpf_cookie has to be different for each addr, otherwise > it's severely limiting. So it would be an array of cookies alongside > an array of addresses ok > > > } kprobe; > > > > Plus new flag BPF_F_KPROBE_RETURN for link_create.flags to > > create return probe. > > > > Signed-off-by: Jiri Olsa > > --- > > include/linux/bpf_types.h | 1 + > > include/uapi/linux/bpf.h | 12 +++ > > kernel/bpf/syscall.c | 191 ++++++++++++++++++++++++++++++++- > > tools/include/uapi/linux/bpf.h | 12 +++ > > 4 files changed, 211 insertions(+), 5 deletions(-) > > > > [...] > > > @@ -1111,6 +1113,11 @@ enum bpf_link_type { > > */ > > #define BPF_F_SLEEPABLE (1U << 4) > > > > +/* link_create flags used in LINK_CREATE command for BPF_TRACE_RAW_KPROBE > > + * attach type. > > + */ > > +#define BPF_F_KPROBE_RETURN (1U << 0) > > + > > we have plenty of flexibility to have per-link type fields, so why not > add `bool is_retprobe` next to addrs and cnt? well I thought if I do that, people would suggest to use the empty flags field instead ;-) we can move it there as you suggest, but I wonder it's good idea to use bool in uapi headers, because the bool size definition is vague jirka > > > /* When BPF ldimm64's insn[0].src_reg != 0 then this can have > > * the following extensions: > > * > > @@ -1465,6 +1472,11 @@ union bpf_attr { > > */ > > __u64 bpf_cookie; > > } perf_event; > > + struct { > > + __aligned_u64 addrs; > > + __u32 cnt; > > + __u64 bpf_cookie; > > + } kprobe; > > }; > > } link_create; > > > > [...] >