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 EF169C4332F for ; Mon, 24 Jan 2022 23:24:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1848308AbiAXXWN (ORCPT ); Mon, 24 Jan 2022 18:22:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:60993 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1454132AbiAXWX2 (ORCPT ); Mon, 24 Jan 2022 17:23:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643063006; 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=067mQ/rXiwBk6yJpI9gB9PMeq9lk0HWia8mGv4MMwCI=; b=i+dJ9cepItwOGjKQrhGY/3NiPfEt/ZP3gwZCGAsqV7T5SSNI+A/h6GJg1Ul3xL3IcTuWPx maWgm+8q0G7e7q7okqxa6u/LidAXexlomHC9FgvG8l/GlEemREm7L29d+r4k4uvfMT93Tn Q+aesxsHuWBQYdwER3XYD2/VlgbIdUU= 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-460-6tDms27aNdy1omFb1A0fRw-1; Mon, 24 Jan 2022 17:23:24 -0500 X-MC-Unique: 6tDms27aNdy1omFb1A0fRw-1 Received: by mail-ed1-f71.google.com with SMTP id i22-20020a0564020f1600b00407b56326a2so3747377eda.18 for ; Mon, 24 Jan 2022 14:23:24 -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=067mQ/rXiwBk6yJpI9gB9PMeq9lk0HWia8mGv4MMwCI=; b=1hM8+f897pY8WjTW1QL/zdeyv0x+JQ80Kr7Pg2QGhqkmHWCJz/o3aYv5Vnu4uPN8BS Fcq+KDTRCzbqfjVGdFmw6v40/JeDJo26khK8QTBdF2DgL8G1mYiAw4OsRjiBxO1kEBCb t1calhfsW4msSu45Hp1QGu+qIIJvpphAsR6VFrXQyk5TYaxyflGLYfkCz5/+UDgICof+ qIkPKDGCpwzQyn91KIAaLukH9s/joOxsJuPeQYhUyiwQhRwkF+u6GdjI8LFC3Kpvil4c 5uYNCKCoEBTWAOGzCtisW2oOMkm5Bp6Fz2SWbvTHCuQmw+xby2bdvF1C7qfnHcgpk/C5 rhsg== X-Gm-Message-State: AOAM5312NrqEDGx2I54PAwgvkLLv0wVCJXibXHWbyz7r6O1uSX3ZyVXu 9UbrG+HjfqSn8+I44kRCICPQKCRmfVadtwVXIMp1m8VpHz5ne+z5b3SomQvBoDZz34Ns7YimM3S ptj/1BGG5HFsHuWR8rQ7EHJCA X-Received: by 2002:a17:906:6a1a:: with SMTP id qw26mr5794945ejc.454.1643063003258; Mon, 24 Jan 2022 14:23:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJw/8716fksKjT7h1gtcfWcvIT83G/teXeHSfZuelcx9XPN1OZLtilO1FMN72ciP7y3cZa5/tA== X-Received: by 2002:a17:906:6a1a:: with SMTP id qw26mr5794923ejc.454.1643063002990; Mon, 24 Jan 2022 14:23:22 -0800 (PST) Received: from krava ([83.240.63.12]) by smtp.gmail.com with ESMTPSA id l2sm7162047eds.28.2022.01.24.14.23.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 14:23:22 -0800 (PST) Date: Mon, 24 Jan 2022 23:23:20 +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> <20220124092405.665e9e0fc3ce14b16a1a9fcf@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 Mon, Jan 24, 2022 at 12:22:10PM -0800, Andrii Nakryiko wrote: SNIP > > > > > > > > (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? > > > > > > In x86, fentry nop is always placed at the first instruction of the function, > > > but the other arches couldn't do that if they use LR (link register) for > > > storing return address instead of stack. E.g. arm64 saves lr and call the > > > ftrace. Then ftrace location address of a function is not the symbol address. > > > > > > Anyway, I updated fprobe to handle those cases. I also found some issues > > > on rethook, so let me update the series again. > > > > great, I reworked the bpf fprobe link change and need to add the > > symbols attachment support, so you don't need to include it in > > new version.. I'll rebase it and send on top of your patchset > > Using just addresses (IPs) for retsnoop and bpftrace is fine because > such generic tools are already parsing kallsyms and probably building > some lookup table. But in general, having IP-based attachment is a > regression from current perf_event_open-based kprobe, where user is > expected to pass symbolic function name. Using IPs has an advantage of > being unambiguous (e.g., when same static function name in kernel > belongs to multiple actual functions), so there is that. But I was > also wondering wouldn't kernel need to do symbol to IP resolution > anyways just to check that we are attaching to function entry? ftrace does its own check for address to attach, it keeps record for every attachable address.. so less work for us ;-) > > I'll wait for your patch set to see how did you go about it in a new revision. I agree we should have the support to use symbols as well, I'll add it jirka