Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1713437pxb; Wed, 9 Feb 2022 02:55:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyQ0p6x9jpu7MQ+w8T9IQIHWEvoLvFBoY9SMf6aNmKGi53Ds7H3P9nLo79kWdtFvNDed1IG X-Received: by 2002:a17:902:d64a:: with SMTP id y10mr1585487plh.66.1644404122313; Wed, 09 Feb 2022 02:55:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644404122; cv=none; d=google.com; s=arc-20160816; b=TYQhDZvBpdPiD+4Kr3dUMKBJ7oVBrmREm2ls4fCy+v883yHNh9vRUXYFlWOl/cdHOd pGIpe9XZTzwEGdGrSQf6qXcvlEg78vi5Gon0wEQjHOi3NXoSyQIUzQmCFMgesz95R6Vu etvG35eRqK4dQK0FnGcfuutt1PlZc/E5saWrJZ8NxRz3A4xYbxIUp0SrgqAF6YdpW/GL AV9YVecyRGmHvKfFexQkjuHsQ0sQ+msm4rqkFkm+taDctIBSf8st6g/4uRzKevJ4JLuV 0UDl/U/n8a3SIDmsWoN8TvVIhgBGj3YlqoXAmTJr/c8W0sF3c9M5bwdwyCOSb0+l7CpF BSeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=HqHf6EUSPiajiRiec1PDYOjczpr3OtMb+80DurOQm1Q=; b=rvPlBeZ/INbDrlU5kZWJp48TBM9aN7RTGVHQ8kKTlP2JJp0JYpNirqOlx47KaNvUCR k7RvyDnx8qWZTxwWjuABWd3cvFCfplCfG94ckRWxhP9mYBjDZIpA0fHaUl0wLWtEzzBn C4XrU0sepJp+bBc1wtKtRGDqOwOtNd/7+oAKV+Ir6Tn2vjr9YeHIs3744pYumZtlTPnH Sius6j5AOVMfqq7cwJ/Mcd/Am7jbnnO7Q5MBZMMmKW22fM7STY/5ql/HUtAi8GxuP2HE /8zExbPwKoSNVSi3aAsq9kvgAoFBwnWlM4/cZSDqRzN+RDzqg33jsNFPgyrZTONifB28 AQGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ezOyJQgy; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id hk2si5699738pjb.21.2022.02.09.02.55.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 02:55:22 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ezOyJQgy; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0E47FE048E6A; Wed, 9 Feb 2022 01:28:49 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352330AbiBHI4K (ORCPT + 99 others); Tue, 8 Feb 2022 03:56:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231657AbiBHI4H (ORCPT ); Tue, 8 Feb 2022 03:56:07 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F2A8FC03FEC0 for ; Tue, 8 Feb 2022 00:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644310566; 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=HqHf6EUSPiajiRiec1PDYOjczpr3OtMb+80DurOQm1Q=; b=ezOyJQgyV11S8QI8LeSycVL1pEqDadexsV7uNrc+JbyLYz+iBP+vcWHQktmIIoyUfeMc9D 5naXFgjdljni+Z6Kt06TZ0SdGpinuNyEvWBKLGh9pFDpa48tPGvfrablRsE6NWNuc8EbJl xIBcYOGfPbBqJ4xuIphX0Vhy4wR8DLM= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-437-mefsVjGMM9uxplibzJVBXg-1; Tue, 08 Feb 2022 03:56:05 -0500 X-MC-Unique: mefsVjGMM9uxplibzJVBXg-1 Received: by mail-ed1-f71.google.com with SMTP id ed6-20020a056402294600b004090fd8a936so9332694edb.23 for ; Tue, 08 Feb 2022 00:56:04 -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=HqHf6EUSPiajiRiec1PDYOjczpr3OtMb+80DurOQm1Q=; b=6JB7vbt7s42lHo7O79DuoEiQlJAtYX+vYUGyx557G8JXmsrzpo3fvUpqv3UTr85sHN gzjyOOHwxmvcxzeRf3wYFxGESJOxisC2o9d8ynx3pHLzgTbpaeNv+g6va6GZCeZg6o76 Wc/MUtBevLatT+ZHNfXcm8Vuy4YVVTBR+pR8yWMlC7jy3LaMJdMyq3xboqRZl8V74i2a p2PacdffFKmY8Dk9GMdLJdUAUqUNeS8G32EliDBDbkrbXusSZSG5kNQbrv3LJDBaPhVM vrjp0ZeZTPMhEoqped/2ly5KLLIinxJ/CShtWQrKXyZJ9jEBFy91uOMZGCwA7NwcUcek WiUQ== X-Gm-Message-State: AOAM533Htgs3TYfhxyKE2urJKFj6gSisKdxQV2BcDBI+SqMNPYo69y9z jP8gbNTEO/BeDsqlG3piceckFLzxWxodyNESjce1BP81MNtRwnza4m6DvsrLGjZqa06zA32fHMQ VnAO3b+fiv33lUYFujFXnuuyT X-Received: by 2002:a17:906:ece8:: with SMTP id qt8mr2833149ejb.738.1644310563747; Tue, 08 Feb 2022 00:56:03 -0800 (PST) X-Received: by 2002:a17:906:ece8:: with SMTP id qt8mr2833120ejb.738.1644310563433; Tue, 08 Feb 2022 00:56:03 -0800 (PST) Received: from krava (nat-pool-brq-u.redhat.com. [213.175.37.12]) by smtp.gmail.com with ESMTPSA id hw16sm1427914ejc.10.2022.02.08.00.56.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Feb 2022 00:56:02 -0800 (PST) Date: Tue, 8 Feb 2022 09:56:01 +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 , Jiri Olsa Subject: Re: [PATCH 1/8] bpf: Add support to attach kprobe program with fprobe Message-ID: References: <20220202135333.190761-1-jolsa@kernel.org> <20220202135333.190761-2-jolsa@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Mon, Feb 07, 2022 at 10:59:14AM -0800, Andrii Nakryiko wrote: > On Wed, Feb 2, 2022 at 5:53 AM Jiri Olsa wrote: > > > > Adding new link type BPF_LINK_TYPE_FPROBE that attaches kprobe program > > through fprobe API. > > > > The fprobe API allows to attach probe on multiple functions at once very > > fast, because it works on top of ftrace. On the other hand this limits > > the probe point to the function entry or return. > > > > The kprobe program gets the same pt_regs input ctx as when it's attached > > through the perf API. > > > > Adding new attach type BPF_TRACE_FPROBE that enables such link for kprobe > > program. > > > > User provides array of addresses or symbols with count to attach the kprobe > > program to. The new link_create uapi interface looks like: > > > > struct { > > __aligned_u64 syms; > > __aligned_u64 addrs; > > __u32 cnt; > > __u32 flags; > > } fprobe; > > > > The flags field allows single BPF_F_FPROBE_RETURN bit to create return fprobe. > > > > Signed-off-by: Masami Hiramatsu > > Signed-off-by: Jiri Olsa > > --- > > include/linux/bpf_types.h | 1 + > > include/uapi/linux/bpf.h | 13 ++ > > kernel/bpf/syscall.c | 248 ++++++++++++++++++++++++++++++++- > > tools/include/uapi/linux/bpf.h | 13 ++ > > 4 files changed, 270 insertions(+), 5 deletions(-) > > > > [...] > > > > > +#ifdef CONFIG_FPROBE > > + > > +struct bpf_fprobe_link { > > + struct bpf_link link; > > + struct fprobe fp; > > + unsigned long *addrs; > > +}; > > + > > +static void bpf_fprobe_link_release(struct bpf_link *link) > > +{ > > + struct bpf_fprobe_link *fprobe_link; > > + > > + fprobe_link = container_of(link, struct bpf_fprobe_link, link); > > + unregister_fprobe(&fprobe_link->fp); > > +} > > + > > +static void bpf_fprobe_link_dealloc(struct bpf_link *link) > > +{ > > + struct bpf_fprobe_link *fprobe_link; > > + > > + fprobe_link = container_of(link, struct bpf_fprobe_link, link); > > + kfree(fprobe_link->addrs); > > + kfree(fprobe_link); > > +} > > + > > +static const struct bpf_link_ops bpf_fprobe_link_lops = { > > + .release = bpf_fprobe_link_release, > > + .dealloc = bpf_fprobe_link_dealloc, > > +}; > > + > > should this whole new link implementation (including > fprobe_link_prog_run() below) maybe live in kernel/trace/bpf_trace.c? > Seems a bit more fitting than kernel/bpf/syscall.c right, it's trace related > > > +static int fprobe_link_prog_run(struct bpf_fprobe_link *fprobe_link, > > + struct pt_regs *regs) > > +{ > > + int err; > > + > > + if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) { > > + err = 0; > > + goto out; > > + } > > + > > + rcu_read_lock(); > > + migrate_disable(); > > + err = bpf_prog_run(fprobe_link->link.prog, regs); > > + migrate_enable(); > > + rcu_read_unlock(); > > + > > + out: > > + __this_cpu_dec(bpf_prog_active); > > + return err; > > +} > > + > > +static void fprobe_link_entry_handler(struct fprobe *fp, unsigned long entry_ip, > > + struct pt_regs *regs) > > +{ > > + unsigned long saved_ip = instruction_pointer(regs); > > + struct bpf_fprobe_link *fprobe_link; > > + > > + /* > > + * Because fprobe's regs->ip is set to the next instruction of > > + * dynamic-ftrace insturction, correct entry ip must be set, so > > + * that the bpf program can access entry address via regs as same > > + * as kprobes. > > + */ > > + instruction_pointer_set(regs, entry_ip); > > + > > + fprobe_link = container_of(fp, struct bpf_fprobe_link, fp); > > + fprobe_link_prog_run(fprobe_link, regs); > > + > > + instruction_pointer_set(regs, saved_ip); > > +} > > + > > +static void fprobe_link_exit_handler(struct fprobe *fp, unsigned long entry_ip, > > + struct pt_regs *regs) > > isn't it identical to fprobe_lnk_entry_handler? Maybe use one callback > for both entry and exit? heh, did not notice that :) yep, looks that way, will check > > > +{ > > + unsigned long saved_ip = instruction_pointer(regs); > > + struct bpf_fprobe_link *fprobe_link; > > + > > + instruction_pointer_set(regs, entry_ip); > > + > > + fprobe_link = container_of(fp, struct bpf_fprobe_link, fp); > > + fprobe_link_prog_run(fprobe_link, regs); > > + > > + instruction_pointer_set(regs, saved_ip); > > +} > > + > > +static int fprobe_resolve_syms(const void *usyms, u32 cnt, > > + unsigned long *addrs) > > +{ > > + unsigned long addr, size; > > + const char **syms; > > + int err = -ENOMEM; > > + unsigned int i; > > + char *func; > > + > > + size = cnt * sizeof(*syms); > > + syms = kzalloc(size, GFP_KERNEL); > > any reason not to use kvzalloc() here? probably just my ignorance ;-) will check > > > + if (!syms) > > + return -ENOMEM; > > + > > [...] > > > + > > +static int bpf_fprobe_link_attach(const union bpf_attr *attr, struct bpf_prog *prog) > > +{ > > + struct bpf_fprobe_link *link = NULL; > > + struct bpf_link_primer link_primer; > > + unsigned long *addrs; > > + u32 flags, cnt, size; > > + void __user *uaddrs; > > + void __user *usyms; > > + int err; > > + > > + /* no support for 32bit archs yet */ > > + if (sizeof(u64) != sizeof(void *)) > > + return -EINVAL; > > -EOPNOTSUPP? ok > > > + > > + if (prog->expected_attach_type != BPF_TRACE_FPROBE) > > + return -EINVAL; > > + > > + flags = attr->link_create.fprobe.flags; > > + if (flags & ~BPF_F_FPROBE_RETURN) > > + return -EINVAL; > > + > > + uaddrs = u64_to_user_ptr(attr->link_create.fprobe.addrs); > > + usyms = u64_to_user_ptr(attr->link_create.fprobe.syms); > > + if ((!uaddrs && !usyms) || (uaddrs && usyms)) > > + return -EINVAL; > > !!uaddrs == !!usyms ? ah right, will change > > > + > > + cnt = attr->link_create.fprobe.cnt; > > + if (!cnt) > > + return -EINVAL; > > + > > + size = cnt * sizeof(*addrs); > > + addrs = kzalloc(size, GFP_KERNEL); > > same, why not kvzalloc? Also, aren't you overwriting each addrs entry > anyway, so "z" is not necessary, right? true, no need for zeroing thanks, jirka