Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3283638pxb; Mon, 24 Jan 2022 06:31:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJzTDg41V+X4t5KT9WnBFPgwC3uQybgfjeJD2iu1fsvh3XX349GOclZSKh6RcJUPV28QpJBg X-Received: by 2002:a17:90a:de8e:: with SMTP id n14mr2157533pjv.122.1643034694250; Mon, 24 Jan 2022 06:31:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643034694; cv=none; d=google.com; s=arc-20160816; b=F/5yFXBXDd4M2BlHN0onCGYic9Z7I8L/I4xJlNfkng7nbYqp3YHbL3zDtMiNZy/Bh6 dQmuXT364ukPg2OZg+dDIjlhFkzjp/tJbpf9sCrV2UedJTiuxXTY7rU6rhUhI7Hdgdcu XCuLDGJL9HhdxrmqOLkRcl6kY7sflx4SSurIqxN4ddl+hIUyKmJFKBTYRrvOY9+0mMT/ ZKQ2lZ79dFIj8DVGiHONTZNBFdB0rWCXrpY/ZEAWl7uvVktFbjZuNW9IIEMyUeCm/1x2 5LfZsx8cqmzrcIYVlzl5irP8CtnT9N4wzQ6EW5yJryXUhZRKnVX5qCRbYmg+E63LyL4M sZ5g== 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=jfrf32ebUcI4fzNTSsB+v8qDSQo+mJTSIXb8h4iPDuo=; b=z2xHnwLXKFMUafyFmKqxqYfwOENjuy5PjWKivYJlPd8Z5wc490X0hJAJcsMoHURJNP WiTRXotguavEdEfrPygg6Q/hlLMMvoeUw6rI9+wd1aLHc4t9FRbSwb/lgmxV9r/mkUW8 OophQML6+0/rcjmMii16gTueSrlK1fCKkrvKxoFoCVEaU83hD27j5roTN0iLzsMdU3BY uq9yRKzqP5TgezTXFPJxWRM0/wCzDcblWT+UrLJOl2jT4W+BNnV+Aaiy2bNG80XJ4GBN ylBZEqqyCRKczqIhQZWpWO2mzBesPoO454etzf3x5RIXI/zoRy4QeqyacaCkIpzh1Qvy ktBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H4UQMmJP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 207si14213594pga.681.2022.01.24.06.31.20; Mon, 24 Jan 2022 06:31:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H4UQMmJP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240478AbiAWXuW (ORCPT + 99 others); Sun, 23 Jan 2022 18:50:22 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:30844 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240466AbiAWXuT (ORCPT ); Sun, 23 Jan 2022 18:50:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642981818; 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=jfrf32ebUcI4fzNTSsB+v8qDSQo+mJTSIXb8h4iPDuo=; b=H4UQMmJPVYonSIGfyETyEjZwNZ8cxNB//ooq07A0DFctjNTOyyYkYQ9IaI/gXxdgULtYBC 8OIaVDkHcxdSuou4xqowo/mwcyQA35L228SxsICrLk7YEDulFG9HL51+/ANghVyjJhb2WN D+VyvN4BbXjz5w8S50amri9hPa0vh4o= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-371-HaeZQPDMPMCpcGKJk_w-mA-1; Sun, 23 Jan 2022 18:50:17 -0500 X-MC-Unique: HaeZQPDMPMCpcGKJk_w-mA-1 Received: by mail-ej1-f71.google.com with SMTP id gb4-20020a170907960400b0069d1ebc4538so1563396ejc.2 for ; Sun, 23 Jan 2022 15:50:17 -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=jfrf32ebUcI4fzNTSsB+v8qDSQo+mJTSIXb8h4iPDuo=; b=6IoPeLShri8hBF5NxVM6/hHl3XiRW3VqYQBuKxy0rDpI5+6syIWJk/asvEAZeKPC0x dcJpJSEp3xVdaltKk57VQgaAE17ha6ms0SwVk2CplnEIIKaqS2whP33ITsBjqdrn/9f3 Be93aTmS3yS35SceaR3wiA4UDVCtTSg26S4geGEhQTu5FwPCN7UdfEQtCogZoq/tpA1I /McGsm7u91RU0Aa6CSH5eixIyyWRCUTNQxbFxepkdZD7JGB/s/eB/XbuJTiN0vCZJ0Z5 jYajq5OyTf3ZNCbEiZYzmiwWjTzfsn4D72G1Q9V4d0hrAox+x5FgOX/0DztMlUHWN9RW iyMQ== X-Gm-Message-State: AOAM5302nQ4xCGOYzU3xdCnrfOPvsJbUjlZfp1pqxhy0agYCZKQ60Y0+ a4mQ98eyf83agzdRqHgjBTCsO4YlZejgasjnV8fQT9VldTLl7vXyzub/pCqrZ02vBSlEZkkhcWM 09d3hDjW85J9ky28NG+ruRV76 X-Received: by 2002:a17:906:150c:: with SMTP id b12mr10315373ejd.284.1642981816141; Sun, 23 Jan 2022 15:50:16 -0800 (PST) X-Received: by 2002:a17:906:150c:: with SMTP id b12mr10315356ejd.284.1642981815887; Sun, 23 Jan 2022 15:50:15 -0800 (PST) Received: from krava ([83.240.63.12]) by smtp.gmail.com with ESMTPSA id w25sm5594985edv.68.2022.01.23.15.50.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jan 2022 15:50:15 -0800 (PST) Date: Mon, 24 Jan 2022 00:50:13 +0100 From: Jiri Olsa To: Andrii Nakryiko Cc: Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , 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: [RFC PATCH v3 0/9] fprobe: Introduce fprobe function entry/exit probe Message-ID: References: <164260419349.657731.13913104835063027148.stgit@devnote2> <20220121135510.7cfa6540e31824aa39b1c1b8@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 Fri, Jan 21, 2022 at 09:29:00AM -0800, Andrii Nakryiko wrote: > On Thu, Jan 20, 2022 at 8:55 PM Masami Hiramatsu wrote: > > > > On Thu, 20 Jan 2022 14:24:15 -0800 > > Andrii Nakryiko wrote: > > > > > On Wed, Jan 19, 2022 at 6:56 AM Masami Hiramatsu wrote: > > > > > > > > Hello Jiri, > > > > > > > > Here is the 3rd version of fprobe. I added some comments and > > > > fixed some issues. But I still saw some problems when I add > > > > your selftest patches. > > > > > > > > This series introduces the fprobe, the function entry/exit probe > > > > with multiple probe point support. This also introduces the rethook > > > > for hooking function return as same as kretprobe does. This > > > > abstraction will help us to generalize the fgraph tracer, > > > > because we can just switch it from rethook in fprobe, depending > > > > on the kernel configuration. > > > > > > > > The patch [1/9] and [7/9] are from Jiri's series[1]. Other libbpf > > > > patches will not be affected by this change. > > > > > > > > [1] https://lore.kernel.org/all/20220104080943.113249-1-jolsa@kernel.org/T/#u > > > > > > > > However, when I applied all other patches on top of this series, > > > > I saw the "#8 bpf_cookie" test case has been stacked (maybe related > > > > to the bpf_cookie issue which Andrii and Jiri talked?) And when I > > > > remove the last selftest patch[2], the selftest stopped at "#112 > > > > raw_tp_test_run". > > > > > > > > [2] https://lore.kernel.org/all/20220104080943.113249-1-jolsa@kernel.org/T/#m242d2b3a3775eeb5baba322424b15901e5e78483 > > > > > > > > Note that I used tools/testing/selftests/bpf/vmtest.sh to check it. > > > > > > > > This added 2 more out-of-tree patches. [8/9] is for adding wildcard > > > > support to the sample program, [9/9] is a testing patch for replacing > > > > kretprobe trampoline with rethook. > > > > According to this work, I noticed that using rethook in kretprobe > > > > needs 2 steps. > > > > 1. port the rethook on all architectures which supports kretprobes. > > > > (some arch requires CONFIG_KPROBES for rethook) > > > > 2. replace kretprobe trampoline with rethook for all archs, at once. > > > > This must be done by one treewide patch. > > > > > > > > Anyway, I'll do the kretprobe update in the next step as another series. > > > > (This testing patch is just for confirming the rethook is correctly > > > > implemented.) > > > > > > > > BTW, on the x86, ftrace (with fentry) location address is same as > > > > symbol address. But on other archs, it will be different (e.g. arm64 > > > > will need 2 instructions to save link-register and call ftrace, the > > > > 2nd instruction will be the ftrace location.) > > > > Does libbpf correctly handle it? hm, I'm probably missing something, but should this be handled by arm specific kernel code? user passes whatever is found in kallsyms, right? > > > > > > libbpf doesn't do anything there. The interface for kprobe is based on > > > function name and kernel performs name lookups internally to resolve > > > IP. For fentry it's similar (kernel handles IP resolution), but > > > instead of function name we specify BTF ID of a function type. > > > > Hmm, according to Jiri's original patch, it seems to pass an array of > > addresses. So I thought that has been resolved by libbpf. > > > > + struct { > > + __aligned_u64 addrs; > > I think this is a pointer to an array of pointers to zero-terminated C strings I used direct addresses, because bpftrace already has them, so there was no point passing strings, I cann add support for that jirka > > > + __u32 cnt; > > + __u64 bpf_cookie; > > + } kprobe; > > > > Anyway, fprobe itself also has same issue. I'll try to fix it. > > > > Thank you! > > > > > > > > > > > > > Thank you, > > > > > > > > --- > > > > > > > > Jiri Olsa (2): > > > > ftrace: Add ftrace_set_filter_ips function > > > > bpf: Add kprobe link for attaching raw kprobes > > > > > > > > Masami Hiramatsu (7): > > > > fprobe: Add ftrace based probe APIs > > > > rethook: Add a generic return hook > > > > rethook: x86: Add rethook x86 implementation > > > > fprobe: Add exit_handler support > > > > fprobe: Add sample program for fprobe > > > > [DO NOT MERGE] Out-of-tree: Support wildcard symbol option to sample > > > > [DO NOT MERGE] out-of-tree: kprobes: Use rethook for kretprobe > > > > > > > > > > > > arch/x86/Kconfig | 1 > > > > arch/x86/include/asm/unwind.h | 8 + > > > > arch/x86/kernel/Makefile | 1 > > > > arch/x86/kernel/kprobes/core.c | 106 -------------- > > > > arch/x86/kernel/rethook.c | 115 +++++++++++++++ > > > > include/linux/bpf_types.h | 1 > > > > include/linux/fprobe.h | 84 +++++++++++ > > > > include/linux/ftrace.h | 3 > > > > include/linux/kprobes.h | 85 +---------- > > > > include/linux/rethook.h | 99 +++++++++++++ > > > > include/linux/sched.h | 4 - > > > > include/uapi/linux/bpf.h | 12 ++ > > > > kernel/bpf/syscall.c | 195 +++++++++++++++++++++++++- > > > > kernel/exit.c | 3 > > > > kernel/fork.c | 4 - > > > > kernel/kallsyms.c | 1 > > > > kernel/kprobes.c | 265 +++++------------------------------ > > > > kernel/trace/Kconfig | 22 +++ > > > > kernel/trace/Makefile | 2 > > > > kernel/trace/fprobe.c | 179 ++++++++++++++++++++++++ > > > > kernel/trace/ftrace.c | 54 ++++++- > > > > kernel/trace/rethook.c | 295 +++++++++++++++++++++++++++++++++++++++ > > > > kernel/trace/trace_kprobe.c | 4 - > > > > kernel/trace/trace_output.c | 2 > > > > samples/Kconfig | 7 + > > > > samples/Makefile | 1 > > > > samples/fprobe/Makefile | 3 > > > > samples/fprobe/fprobe_example.c | 154 ++++++++++++++++++++ > > > > tools/include/uapi/linux/bpf.h | 12 ++ > > > > 29 files changed, 1283 insertions(+), 439 deletions(-) > > > > create mode 100644 arch/x86/kernel/rethook.c > > > > create mode 100644 include/linux/fprobe.h > > > > create mode 100644 include/linux/rethook.h > > > > create mode 100644 kernel/trace/fprobe.c > > > > create mode 100644 kernel/trace/rethook.c > > > > create mode 100644 samples/fprobe/Makefile > > > > create mode 100644 samples/fprobe/fprobe_example.c > > > > > > > > -- > > > > Masami Hiramatsu (Linaro) > > > > > > -- > > Masami Hiramatsu >