Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5501599ioo; Wed, 1 Jun 2022 06:55:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw2RmoY2jpvWUU7ivyasHXlO9O+hisl5pwdYYKxaASbecTX4Y5IvTtXLYeAnBcuCyl2B+F6 X-Received: by 2002:a17:907:1c21:b0:703:c97:ae4c with SMTP id nc33-20020a1709071c2100b007030c97ae4cmr6458354ejc.379.1654091754112; Wed, 01 Jun 2022 06:55:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654091754; cv=none; d=google.com; s=arc-20160816; b=sN5yh1UyBkUV/JvxdXsC0zHFLJ9sGenPC427DnueGTEHRklS+a2isKbH5XkOLHIYME TM9tugFtYSO18aUzbZ71rJXgPeJKYmpvK2rw2fnql+XR4QvRy8vpTTZl3KXhObVV6x+q mYr1dlkHhM0jPYFUvtNwAwbB493QIBVPvSbzX+N65hvp7PKg76DQ1jdS7GpkVq+4gWrN jBIp/2i+xhovRjB3nG3e7uAsYIVPmNCvn50cUtUKYIUBfHWALi+eyvEjbvoZIzV2SF5e 6tL2+buDrBB7tHDpwKA62xnK5Vn/MOtBZm8Lw/kkvvgoZ8xHfLXUhGLMnA4uvV/ks74x 3iuw== 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:feedback-id :dkim-signature:dkim-signature; bh=ibjnI8Geex5eh6AY7BjUezUuIjEtyn8A9+EqUJ4bMcc=; b=ndSWkb90JEnIS+1Fidopr2gYSu67+Gkbd3gpjDfo5B1km3V6Hi+UwPCohO4YP+fPI9 3eD5fvztGge9CW3+wLhfqmYw6RXbhrn6kE60eXKov8/cvvUhIQh52Fqioh52ZgfaQtpy anUQ9Y4t+FHl+UiVDWIFpIfl+fe5ewTTWXfJlFLSQ7ziOQeonO2YOujl3Yj59eEFfDh3 GCCYo2uM41pwvM2JmAPmU8Rduqo7IxO1ZXVJZgGKnRm72+aEwOpdDv3whAuJ6TjqZ1AY HCg5MOAjOgjQC6nab85N1JtqTF9E/p5jEjOMSeDufcdxJUSIPBd6D7ws1BSyiisy9Zmj gHXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (expired) header.i=@dxuuu.xyz header.s=fm3 header.b=Zc4guAAb; dkim=neutral (expired) header.i=@messagingengine.com header.s=fm1 header.b=Ku9WXIBv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jg42-20020a170907972a00b006fe02712b76si1865113ejc.607.2022.06.01.06.55.26; Wed, 01 Jun 2022 06:55:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=neutral (expired) header.i=@dxuuu.xyz header.s=fm3 header.b=Zc4guAAb; dkim=neutral (expired) header.i=@messagingengine.com header.s=fm1 header.b=Ku9WXIBv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242688AbiE3PqJ (ORCPT + 99 others); Mon, 30 May 2022 11:46:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242673AbiE3Pp7 (ORCPT ); Mon, 30 May 2022 11:45:59 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 855174B435; Mon, 30 May 2022 07:56:44 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0CC375C01AA; Mon, 30 May 2022 10:56:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 30 May 2022 10:56:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1653922602; x=1654009002; bh=ibjnI8Geex 5eh6AY7BjUezUuIjEtyn8A9+EqUJ4bMcc=; b=Zc4guAAbjCZPW1oy4/pvYVjbmK L4SIDfKq+K8W2disdVij7aHl9gykkN+c83dd63PVuGVkMTOL7A6r3GVqFvXajcbl u7RBLsAXNT4gJeZTGwAzjhz1hsFgk1JDXagLzunTPgOhFiRbqM2XC97xXN3oIjUv BxqCMDpQXHSYy4AMJzF5c43hSu1GfYEYpiKqSc9Y6sm7Th2RoEYWUsT1H2ztwwpz bwr3xWHc8mqg6yVX1GNZ/CnSihk7trfanrV8kNcjR/EGmc1e5Nbc/URl62EXt2Oe B8m7TBp7ENKru1m0o66Thzx5Bs++AmOFkUYtpHUEfgCRpxikOVXZT4Ty85Kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1653922602; x=1654009002; bh=ibjnI8Geex5eh6AY7BjUezUuIjEt yn8A9+EqUJ4bMcc=; b=Ku9WXIBvVTOendts8TxCy1zIHRrURG4K36Fp6BQwY5Kb IolmOUFnvR09GXd3b8cQCxO4+qnK+DW2kQBtdepoLxssSGJvFGb9SVdttDPXDcR1 AyX+mbTqRILl+cFoNmZUC0fZ9c3Q04LuJcwazdL5HV+JRYffWS2T3xLlu0Ip0LzP MwbAAw5zKJF1UD6S8W/2m3XlO7/JEY8HQ39n3UhkQpAKaKoL5N71783aTV2HetvZ BSIZvOfcfAZqx4sMgtpfYm/hw0F0WWi9BMfns4esJPtirDaAMC08p2m+89JTCDE8 PwVPsK/zEKhCe2s4IIOF/aeps6E4fZokZufLHs0MVQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrkeeigdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfg hrlhcuvffnffculdejtddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddt vdenucfhrhhomhepffgrnhhivghlucgiuhcuoegugihusegugihuuhhurdighiiiqeenuc ggtffrrghtthgvrhhnpeevuddugeeihfdtffehgffgudeggeegheetgfevhfekkeeileeu ieejleekiedvgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegugihusegugihuuhhurdighiii X-ME-Proxy: Feedback-ID: i6a694271:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 May 2022 10:56:41 -0400 (EDT) Date: Mon, 30 May 2022 09:56:39 -0500 From: Daniel Xu To: Song Liu Cc: bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , open list Subject: Re: [PATCH bpf-next 0/2] Add PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE Message-ID: <20220530145639.slbwvbwewonj6im2@kashmir.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD, PDS_OTHER_BAD_TLD,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,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 Hi Song, On Sun, May 29, 2022 at 11:00:48PM -0700, Song Liu wrote: > On Sun, May 29, 2022 at 3:06 PM Daniel Xu wrote: > > > > This patchset adds PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE progs. > > On top of being generally useful for unit testing kprobe progs, this > > feature more specifically helps solve a relability problem with bpftrace > > BEGIN and END probes. > > > > BEGIN and END probes are run exactly once at the beginning and end of a > > bpftrace tracing session, respectively. bpftrace currently implements > > the probes by creating two dummy functions and attaching the BEGIN and > > END progs, if defined, to those functions and calling the dummy > > functions as appropriate. This works pretty well most of the time except > > for when distros strip symbols from bpftrace. Every now and then this > > happens and users get confused. Having PROG_TEST_RUN support will help > > solve this issue by allowing us to directly trigger uprobes from > > userspace. > > > > Admittedly, this is a pretty specific problem and could probably be > > solved other ways. However, PROG_TEST_RUN also makes unit testing more > > convenient, especially as users start building more complex tracing > > applications. So I see this as killing two birds with one stone. > > We have BPF_PROG_RUN which is an alias of BPF_PROG_TEST_RUN. I guess > that's a better name for the BEGIN/END use case. Right, sorry. Was getting names mixed up. > > Have you checked out bpf_prog_test_run_raw_tp()? AFAICT, it works as good as > kprobe for this use case. I just took a look -- I think it'll work for BEGIN/END use case. But also like I mentioned, BPF_PROG_RUN/BPF_PROG_TEST_RUN support for kprobes is probably still useful. For example if kprobe accesses 13th register. I suppose the raw_tp 12 arg limit could be lifted but it might be tricky to capture that logic in the absence of something like `struct pt_regs` to check the ctx_size_in against. Thanks, Daniel