Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1059377iog; Fri, 17 Jun 2022 22:37:57 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tQd84wyZFJKZkXVOINzV5chAdw1nylIIEPiQo+8CAJzdtSTjio2vJtAPILXO9xdfie8loH X-Received: by 2002:a05:6402:2682:b0:42e:1c85:7ddc with SMTP id w2-20020a056402268200b0042e1c857ddcmr16271542edd.143.1655530677426; Fri, 17 Jun 2022 22:37:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655530677; cv=none; d=google.com; s=arc-20160816; b=GSSaPVOKizNV2vbbNTig3d5IiYcAeu2R0K76Jsf20u9L+Z29ulQDZteVuqHryf5PJa jwjEOMCk3Kln0PAjIogGjAev7AFQjFWmGTsvfoqW2/UUSozWcI1Rc8wQInUJzfpFC+S0 Rz/UPN6lNjdKpw2Omel6UnFVvZMlBweJK312EFKe7iI/x+J1YXWZkGCZB7xm65+W8KJx bSgX4gAWhoLYKunVToV8HOMnlT3K/KytXPFG2fTcs9E7KVIuSSZvCOIp/+mnHdXaiSd1 z0ezR/weZVjlKxHHO1MQDxrQr+MeTD5VSD5MT1lagA/cSu+a6r3iRwY0yB6kSGaVnc7d pQ4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=xCv5ZFaf8lE9/RCZn/mnFHKDQpvJJAzq648WOUNKZXI=; b=qqS2/TAgRtEWnEtMl/RG7rmyP0csjcRnNTNviuvQzhYS6K5LbhvQ4e/3qqXkLSdLOv D/UT+CUUdxpNjCdfeXGYnm2WKE8W5NY14wUnjcwJS4/czDFl+3yQU+CqFfvLGZseRlc6 IZHmEpzvmbNnnw3mSmnRTqkucEQwaGPsm308bT8I7Hvdsoi6Z8drtJH4IA2qdMFYJzn7 RwvkcLiHtu8VEZxhQJxqUZ2YIzJ+1u9aMfQf6lvgRfNU1bGnv9RXmcaNoRYZVvggt+ou tAXr0xrxZdG15vQHTUdN4EyKtlxJSaPePFNky/pcuIYzDuxovgqEfifkzsj1+mqBgd+x FODQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=JPWBm5Mb; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m11-20020a17090677cb00b006f3a36fe538si3147486ejn.259.2022.06.17.22.37.15; Fri, 17 Jun 2022 22:37:57 -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=pass header.i=@gmail.com header.s=20210112 header.b=JPWBm5Mb; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232151AbiFRFbQ (ORCPT + 99 others); Sat, 18 Jun 2022 01:31:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbiFRFbP (ORCPT ); Sat, 18 Jun 2022 01:31:15 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D0D06006B; Fri, 17 Jun 2022 22:31:14 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id fu3so12118501ejc.7; Fri, 17 Jun 2022 22:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xCv5ZFaf8lE9/RCZn/mnFHKDQpvJJAzq648WOUNKZXI=; b=JPWBm5MbnBHiAlK92Qz+JGFp5rZR9xLLsktGh2cLPQzh1z2pDSCcsl8HmRwzoSX4Er ku5BauTtY8t+KA0QnhHlDvB0stpBeVXZbWithupIrhLXvfV9lt3J9BVpu5oZ9mbMErIP g0y4xrJUbfZBw5tZJxLQANa05UP84bmbnB0B5gCf/iy88mr+VxhV6hAuHOW9go+sDCpM yJ3kYB/vZR5LkTHVy84XLAqqYmZ84GRG+IFuxOgtEOP+zExtCcrZeDfT5nhP/bwYSvXY AUM9YIJJxPNTQfGa8Zs1mkYirOhvpoQHjBxOvxKV0oIX5uldpbDkacPWLSiLx+gGR4fo fSFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xCv5ZFaf8lE9/RCZn/mnFHKDQpvJJAzq648WOUNKZXI=; b=W8lPJmtKmj8iZPiF0GrRxZ6NMNZfL3i3Ads2LUuwF66w05PZo4UXQ+eO6nCL28uyGn mKO5JY1Ejl3uLoPU4iBOFLIB0NsIgAiimvswrHW52aKkET64/DoeHuX6e+fRwZV3n0yQ UxSlNFBEe6DD1nDSa4naaCwnVpskkax02vScQFjiL4u9IEeiSZPG4mbcEUeJGCTc2RWw 4uW5uSvyt1CP25ZqnIR1KRjx5A2hgzxItIXihL5rJM0zc96GeGf+gUoZ3EJnH+x5f09o 9e50LMOON9L8qnR8tzgQcnvXp1h3cBaEQ9hT1U7NQSRelk022QSJQvyqUjNGxeeLJO7a 6Exg== X-Gm-Message-State: AJIora+xmoQkajuhEbMpa4mCeJa6xkriuiXpx5SP5hcNKWEkXISls3bO uf3CxJDFGQdwSLxDxTJtzjTngOIu8WjUbWUo11Y= X-Received: by 2002:a17:906:649b:b0:711:fde7:be43 with SMTP id e27-20020a170906649b00b00711fde7be43mr12454129ejm.294.1655530272557; Fri, 17 Jun 2022 22:31:12 -0700 (PDT) MIME-Version: 1.0 References: <20220614084930.43276-1-nashuiliang@gmail.com> <62ad50fa9d42d_24b34208d6@john.notmuch> In-Reply-To: <62ad50fa9d42d_24b34208d6@john.notmuch> From: chuang Date: Sat, 18 Jun 2022 13:31:01 +0800 Message-ID: Subject: Re: [PATCH] libbpf: Remove kprobe_event on failed kprobe_open_legacy To: John Fastabend Cc: Jingren Zhou , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 John, On Sat, Jun 18, 2022 at 12:13 PM John Fastabend wrote: > > Chuang W wrote: > > In a scenario where livepatch and aggrprobe coexist, the creating > > kprobe_event using tracefs API will succeed, a trace event (e.g. > > /debugfs/tracing/events/kprobe/XX) will exist, but perf_event_open() > > will return an error. > > This seems a bit strange from API side. I'm not really familiar with > livepatch, but I guess this is UAPI now so fixing add_kprobe_event_legacy > to fail is not an option? > The legacy kprobe API (i.e. tracefs API) has two steps: 1) register_kprobe $ echo 'p:mykprobe XXX' > /sys/kernel/debug/tracing/kprobe_events This will create a trace event of mykprobe and register a disable kprobe that waits to be activated. 2) enable_kprobe 2.1) using syscall perf_event_open as the following code, perf_event_kprobe_open_legacy (file: tools/lib/bpf/libbpf.c): --- attr.type = PERF_TYPE_TRACEPOINT; pfd = syscall(__NR_perf_event_open, &attr, pid < 0 ? -1 : pid, /* pid */ pid == -1 ? 0 : -1, /* cpu */ -1 /* group_fd */, PERF_FLAG_FD_CLOEXEC); --- In the implementation code of perf_event_open, enable_kprobe() will be executed. 2.2) using shell $ echo 1 > /sys/kernel/debug/tracing/events/kprobes/mykprobe/enable As with perf_event_open, enable_kprobe() will also be executed. When using the same function XXX, kprobe and livepatch cannot coexist, that is, step 2) will return an error (ref: arm_kprobe_ftrace()), however, step 1) is ok! However, the new kprobe API (i.e. perf kprobe API) aggregates register_kprobe and enable_kprobe, internally fixes the issue on failed enable_kprobe. But above all, for the legacy kprobe API, I think it should remove kprobe_event on failed add_kprobe_event_legacy() in perf_event_kprobe_open_legacy (file: tools/lib/bpf/libbpf.c).