From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 6CCFE1C3F0C for ; Thu, 12 Feb 2026 15:20:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770909639; cv=none; b=l2QhR/wksErQB+s2FR8Y62gDw8KFz4XYtpCuHUFGFUiuGJejKQPDJuKG/ygPMun/36Jv0GS+HzlKyM6PsHQlPbdxp2soWGJkKJUEPHIrK6p7FKTvhyqcW6QNewpWktM+5KWHOoB1Qt6Bt4XH+VfvyS8KvvOquAUGE3PRJVson4M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770909639; c=relaxed/simple; bh=Gqxx94/TBZoBI7LhDZx99gNDM2173gryzavutBlKrrk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=SEhTLousApTBEP308OF4QsNRRdyTaA+VNrrsv02rP4aKoYrIKgorvw9b3jKpPXOO0lgdq3TTws/3DXIwepQHmoNXbrfI/KEUbig1SMUEi3F2ODa0XupVcj7wnCoDOQ+ZCZCvhOZpoAX27GXFlc+W3miLG1NjP7YhA7MQhlF3hPM= 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=W0kQujF4; arc=none smtp.client-ip=209.85.214.179 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="W0kQujF4" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2aaf59c4f7cso15840755ad.1 for ; Thu, 12 Feb 2026 07:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770909638; x=1771514438; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=5OC9IS7FbuAeXEzPS/HflFuL5Amk/C9+TIXAnhWmuiU=; b=W0kQujF45qUs7PfgMC9ty3powhHueTtmtReIPnbHsoDZxQqvn5Wlukgu3XeWpbWFv7 7NsgpVONk0Yp2UpoeAKs6ywhakx1zkmif2lvQUvdZzKT8bHkXTl7q1Mw/nAUTf7h076B 1TzExGDmfpBzLB+5oZSjGBM6dTQBrQj5C7BAwvFAzB3zkrH4YR+xrBsFPQxRLGXVAu50 Q1Zsn/rIYUkNRqHp7spQvOQPPJsmm2Va7vTTIcRFJGDAd+8LHZQEDyJuVIk9hbarSvgx s2+A9/sN/u1+F70foNVhPVOzl43SQTRQttKq7ggArFl/xm/C6+nkw6m6XQm7j1Eq3Uw0 tntQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770909638; x=1771514438; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5OC9IS7FbuAeXEzPS/HflFuL5Amk/C9+TIXAnhWmuiU=; b=wdEK+3Nvz11/Pn6AIRXw6QDwyP5W5xUeTnh5vQQ9+ZNnW9JgY3OdUMczX9LG5FAmkO 5l68I3EozHlDH846hNaN0+bAhx/Y5EIqyd4GOTI0l9bFOrvpxJ42GfQdF9fsYp+U/nlK KWwIm/SAml4Ie6mkHuv7Yrt80fMqI+qbG2EZzoE9tRwPyFveXL00SotTiEgnELoSVh2+ 0pKwdjJ5106VyCRmxzNSu+8FcK+5vCOTEAX3CKYhqFHHLskpTo+HUJKg9T+uyKiDzZxe 61UaasKHUgtSOj+TXrosLNguuB3EhDwBAybxmjZK3bbYLcLgomLtP3ByW3bv3JCaJCN/ PFDw== X-Forwarded-Encrypted: i=1; AJvYcCVsPMwp7GT52yjGeJspN14Qfdhzhte69dvIFMfgRonMts3b0vsJwOui7jyApOhInkbWlZjtOA7qckHB9Bg=@vger.kernel.org X-Gm-Message-State: AOJu0Yzj4XntUYOfFofcG24wG5uXj1qODlcSh+Zi88aOjOln3ELR4Uot T8NJlBNBYWGYGARvZGOeLwizcxy0dPuDkyCaFOtVWH3YMnv5AF2zdB8hLEGeeg== X-Gm-Gg: AZuq6aL9vdY8V5yrgs/xqP6WY17paP2/+Jps/AqnrE3NuyMGCXLgeePuv+hDU9tl9gK 5Ixbx6bU6rvsuF365dWl1XE8n0y7iDhuRLfGD+LKAisKWCHpLwq8MZn4PpVLV/1pFLH/vS6slrN URmOZGPPa9eTFxh9S0QMgdrSemQoNBQxk4VR0xybZeqn8ynAIQiNunBIEKAW1BkC1nH2APYzKDP JI71qvViHizEnXTeb2AUhkybUkkLjHPWrRVlpPo5XNcLiDvBVDden6fxVGXsqzd1anndVcEkNVW fx4vZiIrCSvBgoMN1kDVLmIeEs3HQ+aqsaWDOmRuwqY+v3XBldZJLfQYmDl9RVg60LZOzhM/GnM uXQcK6OoNp/0TIx1mzbljftgX+Ft9mH0lic6DkYKjW/S90rQeAdo1TuZaRq5h97S5Y/yzz8VIBT TcHWHVNgACDR+bVd48L2B04UbNlAF6NU6S2bj/8hxfizbj+7G2tjO7YzLBj/zBAdlXb8k= X-Received: by 2002:a17:903:1986:b0:2aa:d29f:1441 with SMTP id d9443c01a7336-2ab3b183d24mr24557415ad.2.1770909637499; Thu, 12 Feb 2026 07:20:37 -0800 (PST) Received: from computer.goose-salary.ts.net ([2a09:bac5:40b4:a82::10c:60]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ab2984ad4asm55943795ad.6.2026.02.12.07.20.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Feb 2026 07:20:37 -0800 (PST) From: Varun R Mallya To: andrii@kernel.org, alan.maguire@oracle.com Cc: ast@kernel.org, daniel@iogearbox.net, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, varunrmallya@gmail.com Subject: [RFC PATCH bpf-next 0/1] Upgrading uprobe and kprobe to their `multi` counterparts. Date: Thu, 12 Feb 2026 20:50:12 +0530 Message-ID: <20260212152013.17351-1-varunrmallya@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This RFC patch explores auto-upgrading standard uprobes to use the multi-uprobe infrastructure when supported by the underlying kernel. Background: The BPF token concept allows privileged operations inside non-privileged user namespaces. However, attaching standard uprobes and kprobes currently relies on the perf_event_open() syscall, which is not BPF token-aware. Multi-uprobes and multi-kprobes bypass perf_event_open() entirely, attaching via the bpf() syscall instead, making them compatible with BPF tokens. To bridge this gap, the goal is to switch SEC("uprobe") and SEC("kprobe") to use multi-uprobe/kprobe under the hood. To maintain backward compatibility for cases where singular uprobes are explicitly desired, this patch also introduces SEC("uprobe.single") and SEC("kprobe.single"). Current Implementation: The decision to upgrade is made at BPF program load time in `bpf_object_init_progs()`. If the kernel supports FEAT_UPROBE_MULTI_LINK, we intercept programs with section names matching "u[ret]probe" and change their `expected_attach_type` to BPF_TRACE_UPROBE_MULTI. During attachment, `attach_uprobe` checks this expected type and routes the attachment to `bpf_program__attach_uprobe_multi` accordingly. I am currently hitting an issue with selftests, and I would appreciate some guidance before proceeding to implement this for kprobes and fix it for uprobes. Selftests that rely on auto-attachment pass. However, tests that bypass auto-attach and manually call `bpf_program__attach_uprobe_opts()` are failing. Because the program's `expected_attach_type` is modified to multi-uprobe at load time inside `bpf_object_init_progs()`, directly calling the legacy attach options subsequently dies due to the type mismatch. How should we handle legacy manual attachments for auto-upgraded programs? Should `bpf_program__attach_uprobe_opts()` be taught to internally redirect to the multi-uprobe path if the expected type was upgraded? Thanks, Varun Varun R Mallya (1): libbpf: Auto-upgrade uprobes to multi-uprobes when supported tools/lib/bpf/libbpf.c | 42 ++++++++++++++++++++++++++++++++++++------ 1 file changed, 36 insertions(+), 6 deletions(-) -- 2.52.0