From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F3193290AF for ; Mon, 30 Mar 2026 14:53:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882423; cv=none; b=WsQAaBPAOAf6l9HQYPejrHZlReTnWDqj1kESyzlP9pEg41qcvdjMSd1N8cV3yP4F/H6zGzeJCA8o+gsXjmRmHMxkfKd1mEq4MIYnRSEKZFK8gdCvOaY2CrZ/nda2WDOpAkTBg+K+HX4oDevBXkXgHmv55Z7QDlgnsDWFBYcrDsM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882423; c=relaxed/simple; bh=uFKFf9VWROyzVIe6+OengUpbxVbnqSI5Vcr+qWrGods=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C47BstjZtNOlClN8ECIgA8FAO0VziMheOVigcCBnMYr5h/xTezQm0JYS1unC0zfp0B5x0s2NlNijNLWcnw7AhhNPhNkWhjBB9CF/q1i+pXwTZ6xBWBybRij0dMAQvz1gaTxViMSouquv8w/xAPDYhqsf5j2iIunaCNKbmZ++wi4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fh3vU7vt; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fh3vU7vt" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-439c56e822eso5028390f8f.2 for ; Mon, 30 Mar 2026 07:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774882420; x=1775487220; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=1c6BCRp+6zfBa+LZeKBNzRwbiUzChN7CKkj5VTwZzb4=; b=fh3vU7vthyfo7dMZCMqM9aIuMjqVHKQBQQk0z1mQO6w0QIpzb3/DuGmredeBdCK9pi XsGTjvnWTbC6YwiZ7LByglFLvhkAweTEd/SXQzcU0aK3p9x4GfuoEb7bz5ArpkeMJKnq nNxQsNunQN9D6dcPodjYalEqKU3s+UgKc1GZ+3/2F9aXkXDJD7YOOUiRjFrWSYdsUQ2B eft60Rrd2e/LHoScZcOt0PNrcShMfDpTr+0iIrK3D3zqGuugLtVCVHa+BcNKCt8TRs0F TIJPgaTTJ9ErBy4lg39pGJSHQymEabAwAdHL9PQf6fgO9qBauQEWR/Is2SwyEzfR5AUN 79mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774882420; x=1775487220; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1c6BCRp+6zfBa+LZeKBNzRwbiUzChN7CKkj5VTwZzb4=; b=hjaZcbdev60KjGQI7/AClKZ3OZnA59aSJ+BToiKW0O+CYw9RqmVKw9muxOyDfhHIto rOr17C3fQ7jqe+Bk3OIJ7Ss20ZzoXSzBFdalFNnoCacE6yINKcNamgdIiqT+2SJuUpSy FhAo+5qztL8DvS8t4ZOljYI0jhmqeh9Ss4adQfJDgBAWbru2gyqqs+IpZ4GxCo7HNdUu 2dbB3OaZ1P1uwVcxuBDOuub7Vg9oh+TxXHDGma8ouHbLJOwlL2474aWovXaKIzyMO0N8 Ual+NCjanotrHPgWBFK2UNsm590DhGUGxjPSnswYZ2mzYa/ZVbq5JcyrvAjclYJZ1Ssj l+HQ== X-Forwarded-Encrypted: i=1; AJvYcCUHt+zL1VsaqxFNGDpWW6AkdBNJ+9ghXswc7k7ZxAog03qz/S7o9/sZTqkpCPBS57tiyDNJBvsrv17eUos=@vger.kernel.org X-Gm-Message-State: AOJu0Yyelq8G5xZoSb/CURERU9jYfJkaoBj1E0UVAuY+fZ4x9ISGpGMq 9u1rgAsZrjGFipFKykXAge6NiLacJcM6MF4ec6hWTPbl0npqk5EZn6AU X-Gm-Gg: ATEYQzxD81bwGPVr+vs6d0j8gKtDjxTvz2EkKSgTpTW9Jk2olZ+WhyNif/HRkMd/lKF xmXs/YQZbdhUPucFTu8nQevbCRN3DjAJ+HsZocxVO5yVgqLyaECAo4YS3bIeRPaMxGT5sKwirkx AeMUed5sYvPY2Sh8ARPqBEsGCRUkiUCTmv6sMxzNsp6YY6LGhSFLcTCozU/zw05PzGUqa2rqfce paMWUR3LVxKjOkuIIqUD4vu+o9TWEt76sRjnRJgx/Nqk2udSDSBgHWXwEtNYDfkqjTxqL0WpYCB j/egMCvJmaq6BsjJR3W7bWGNnnp6eQz6O9HegP2DIc2EYaHRRUgp3/Y4OoNRRtgFO5fIQ8ZmBBe wUspSyxWgL5M2kw1RnD30mm8rY0ZJDQMPdu3SlxJ1qPf3wbWEnARFutxbyUJAZZC+FGsUtPXsnb OQ0m6j/m22R8BiEwxTPGyLUCOJ2n9rPrysKZuS4/hYNurIPKUJyurkyXM9IQ== X-Received: by 2002:a05:6000:25c7:b0:43c:f95c:3e66 with SMTP id ffacd0b85a97d-43cf95c3ecemr10655210f8f.21.1774882420171; Mon, 30 Mar 2026 07:53:40 -0700 (PDT) Received: from krava (cust-west-par-46-193-1-135.cust.wifirst.net. [46.193.1.135]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43cf21e9e24sm18362075f8f.10.2026.03.30.07.53.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 07:53:39 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Mon, 30 Mar 2026 16:53:38 +0200 To: Varun R Mallya Cc: andrii@kernel.org, alan.maguire@oracle.com, yonghong.song@linux.dev, song@kernel.org, bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, memxor@gmail.com, eddyz87@gmail.com, martin.lau@linux.dev, menglong8.dong@gmail.com, puranjay@kernel.org, bjorn@kernel.org, leon.hwang@linux.dev, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH bpf-next v2 3/3] libbpf: Auto-upgrade kprobes to multi-kprobes when supported Message-ID: References: <20260330110019.549079-1-varunrmallya@gmail.com> <20260330110019.549079-4-varunrmallya@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260330110019.549079-4-varunrmallya@gmail.com> On Mon, Mar 30, 2026 at 04:30:19PM +0530, Varun R Mallya wrote: > This patch modifies libbpf to automatically upgrade standard > SEC("kprobe") and SEC("kretprobe") programs to use the multi-kprobe > infrastructure (BPF_TRACE_KPROBE_MULTI) at load time if the kernel > supports it, making them compatible with BPF tokens. > > To maintain backward compatibility and handle cases where singular > kprobes are required, new SEC("kprobe.single") and SEC("kretprobe.single") > section types are introduced. These force libbpf to use the legacy > perf_event_open() attachment path. > > The following explain the reasoning for changing selftests: > - test_fill_link_info.c kprobe→kprobe.single: > this test calls bpf_link_get_info_by_fd and asserts > BPF_LINK_TYPE_PERF_EVENT and it explicitly needs the perf_event > attachment path, which breaks after auto-upgrade to multi. > > - test_attach_probe_manual.c kprobe→kprobe.single, > kretprobe→kretprobe.single: > this test exercises all four explicit attachment modes > (default, legacy, perf, link) and PROBE_ATTACH_MODE_LINK > creates a perf_event BPF link which the kernel rejects > for a prog loaded with expected_attach_type = BPF_TRACE_KPROBE_MULTI. > > - missed_kprobe.c kprobe->kprobe.single: > The link is explicitly checked in the tests due to which it fails if > we do not specifically kprobe.single this. > > - get_func_ip_test.c ?kprobe→?kprobe.single: the ? is stripped from > sec_name by libbpf at init time so the prog still gets auto-upgraded. > It is then manually attached with a non-zero body offset, > which kprobe_multi doesn't support. > > Signed-off-by: Varun R Mallya > --- > tools/lib/bpf/libbpf.c | 61 +++++++++++++++++-- > .../selftests/bpf/progs/get_func_ip_test.c | 2 +- > .../selftests/bpf/progs/missed_kprobe.c | 4 +- > .../bpf/progs/test_attach_probe_manual.c | 4 +- > .../selftests/bpf/progs/test_fill_link_info.c | 2 +- > 5 files changed, 61 insertions(+), 12 deletions(-) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index bd7b6f486430..9d0a36f8279a 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -8265,6 +8265,24 @@ static int bpf_object_prepare_progs(struct bpf_object *obj) > } > } > > + if (kernel_supports(obj, FEAT_KPROBE_MULTI_LINK)) { > + const char *sec_name = prog->sec_name; > + /* Here, we filter out for k[ret]probe or "k[ret]probe/" > + * but we leave out anything with an '@' > + * in it as kprobe_multi does not support versioned > + * symbols, so we don't upgrade. Also for '+' as we do not hum, kprobe versioned symbols? > + * support offsets. > + */ > + if (((strncmp(sec_name, "kprobe", 6) == 0 && str_has_pfx ? > + (sec_name[6] == '/' || sec_name[6] == '\0')) || > + (strncmp(sec_name, "kretprobe", 9) == 0 && > + (sec_name[9] == '/' || sec_name[9] == '\0'))) && > + !strchr(sec_name, '@') && > + !strchr(sec_name, '+') && > + !(prog->prog_flags & BPF_F_SLEEPABLE)) is this check necessary? > + prog->expected_attach_type = BPF_TRACE_KPROBE_MULTI; > + } > + maybe add the upgrade logic into separate function, like static int upgrade_program(struct bpf_program *prog) > err = bpf_object__sanitize_prog(obj, prog); > if (err) > return err; > @@ -9924,10 +9942,12 @@ static const struct bpf_sec_def section_defs[] = { > SEC_DEF("sk_reuseport/migrate", SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, SEC_ATTACHABLE), > SEC_DEF("sk_reuseport", SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT, SEC_ATTACHABLE), > SEC_DEF("kprobe+", KPROBE, 0, SEC_NONE, attach_kprobe), > + SEC_DEF("kprobe.single+", KPROBE, 0, SEC_NONE, attach_kprobe), > SEC_DEF("uprobe+", KPROBE, 0, SEC_NONE, attach_uprobe), > SEC_DEF("uprobe.s+", KPROBE, 0, SEC_SLEEPABLE, attach_uprobe), > SEC_DEF("uprobe.single+", KPROBE, 0, SEC_NONE, attach_uprobe), > SEC_DEF("kretprobe+", KPROBE, 0, SEC_NONE, attach_kprobe), > + SEC_DEF("kretprobe.single+", KPROBE, 0, SEC_NONE, attach_kprobe), > SEC_DEF("uretprobe+", KPROBE, 0, SEC_NONE, attach_uprobe), > SEC_DEF("uretprobe.s+", KPROBE, 0, SEC_SLEEPABLE, attach_uprobe), > SEC_DEF("uretprobe.single+", KPROBE, 0, SEC_NONE, attach_uprobe), > @@ -11769,6 +11789,25 @@ bpf_program__attach_kprobe_opts(const struct bpf_program *prog, > offset = OPTS_GET(opts, offset, 0); > pe_opts.bpf_cookie = OPTS_GET(opts, bpf_cookie, 0); > > + /* This provides backwards compatibility to programs using kprobe, but > + * have been auto-upgraded to multi kprobe. > + */ > + if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI && > + offset == 0 && attach_mode == PROBE_ATTACH_MODE_DEFAULT) { > + LIBBPF_OPTS(bpf_kprobe_multi_opts, multi_opts); > + const char *syms[1] = { func_name }; > + __u64 bpf_cookie; > + > + multi_opts.retprobe = OPTS_GET(opts, retprobe, false); > + multi_opts.syms = syms; could we do directly: multi_opts.syms = &func_name; jirka > + multi_opts.cnt = 1; > + bpf_cookie = OPTS_GET(opts, bpf_cookie, 0); > + if (bpf_cookie) > + multi_opts.cookies = &bpf_cookie; > + > + return bpf_program__attach_kprobe_multi_opts(prog, NULL, &multi_opts); > + } > + > legacy = determine_kprobe_perf_type() < 0; > switch (attach_mode) { > case PROBE_ATTACH_MODE_LEGACY: > @@ -12223,14 +12262,24 @@ static int attach_kprobe(const struct bpf_program *prog, long cookie, struct bpf > *link = NULL; > SNIP