From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) (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 EA7D036166D for ; Fri, 13 Feb 2026 17:22:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771003342; cv=none; b=GaXjLhvNUE/J1o7CNy9zEynYGL5wTgHyHHbjRvx6+iBy1NGVa1IqQkkDZq18z04h2BNWdcY56y3da2R0WpJqcYa3sxD0GR+Twk8FmEg/0fSZ/Qu+3YcBPQQmenBV1Yqo5Rt+OHS9Ph9HoFPhoLwf7AmN6CiRZqAhVkHBvz/J0AY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771003342; c=relaxed/simple; bh=Li7RA7rb91C+NtViKhE1zNDAnOUxmCPSlSLpIaAiwX8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=InTsKllrLs91cYMG570Jxht6B73FomdU2hdNoSFu1BXXxGeYdc3atY1I/5SFc/xyycGQS6yghM8p9pqnR12Earts9DhmZw2Ra5cBpXkNn+08zcfGduFHmB6iEd3ypmkenSW3wEEIZBPhpaXT8wp7NCbOQvmyGPwHvYVZ9MQm9MU= 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=cjwWXoH9; arc=none smtp.client-ip=209.85.215.173 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="cjwWXoH9" Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-c6de0364915so587782a12.2 for ; Fri, 13 Feb 2026 09:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771003341; x=1771608141; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Li7RA7rb91C+NtViKhE1zNDAnOUxmCPSlSLpIaAiwX8=; b=cjwWXoH9ItHJw/oYsEa5vWFAr2epzYrYfN0gYPTeKElg4h82wrCwNpuSqECjnPy6Gq ItSxSQhKXvJVTB+L6H8810Wi2C33bsuUlNwgEBXpj7EJZsGTSv8xkXqX7PP108RVzDiD 4vzqpkuKBrtzzIBpix/3aqTAyFCpPInY6BW9XeVcE7jTq0uWShZoE2lRf7EPR98mL4NC NBQkSE9fpS7t7KqIqXaF/aXVlrvLwml4KUj/Ul9TOvz9Cm+GmNzBksTegM3WFYjP2lPX 8ax5BqQV8V/E4aaxutrDvu0xuqqy/F0QnYY12/4CoQvdNf9huhH7P69n/35pD+zflkCC tRfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771003341; x=1771608141; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Li7RA7rb91C+NtViKhE1zNDAnOUxmCPSlSLpIaAiwX8=; b=rl+UqAhfBNzIixeuhOP6Qa4f60Wr2dLs6AB0wOhwJhZyGnA4TCfFIKJA14Uk3pOx61 QfBRkP2OpN2CYMl+5K2th/cA/QYQvlX/WSHlWzwNzJrl+8Bx4kmKCvi+FD5NaJZhNhl3 C4CmNNOWlwHXiUKsMxlGT9mbZglf2lxdUPu7Y28H8dB8shE3ME/1pvGibPr1Go/TVQky +QUsBnS+4lUddLJvl/XH2NcILbBRPPnOtbJ4sIX4kCObaF6iL3rb5pm0sv7CXRFfBoi0 IzCQf2Wfi9DRYavzo8ujAHFT/Lag7+flFvU3Wdxu1s9Tn0DL8DerLJHQ+aZEWLSS4CxX 6Lrw== X-Forwarded-Encrypted: i=1; AJvYcCVr+JaUCixRs3UBZtBtPa4M8rjkHtdKD9p8fHIxTB1wDGSGjdFiP/zJ4pGI0jTCRmbysilMaPNZ4kgkKKA=@vger.kernel.org X-Gm-Message-State: AOJu0YxmZgMfudyxcXQotI1dKzWmNyyB5RP+duMeBv4qwzaBX17DakTs 2PXRL/kWmUTHBkQmSD+YeNhdBHx1axajIKYS5g2p6yAYvTz7p62/bt4O X-Gm-Gg: AZuq6aIivSvlnI6TYXFo8OcwyfLbLhZ32+fZkfRQPpY6WFKcFk0P1TM9xKvEb4VtGBL jKPUXk6HO4Rrii19L+bx3J5EpZAvFBPCK0CK9h0DMPN/uYEWIWVHAIBl3UoBu4DDenkUOsiGVCm QabxTRnYMNmmT+nwYdCq1qB9U7BuoO6EKTaMKQN6ZI0y+1edPoA1UYTgpl1Cez6L61nDvdXF1+u g3wJkv7peQOLs2LJSJ3PFMEG/GuxKoaP/tCclDlA5gHCoGfZeCaKOfyOkyUOzpAEPkorj0aE+GK Mt2rc8PLlyog1bavRpQIPGnqrWwoQfEAY7jUJPFGxdht0ooniaHbIUDdr2USbuJmyStxuWLLqI/ Cw6N/C5WVg2g5fZewcSakhC9B9Ky8/9A2ez+9bJgqVuf0XtaFahGVlHMDfF1dzsL5PYz7yFoS2/ SC3owAJZ4BP6bLohrdQxqwcJIwsf3pkfvOJRWGDES+JdMyCpU= X-Received: by 2002:a17:90b:3ecc:b0:353:e91:9b2f with SMTP id 98e67ed59e1d1-356a7aab90emr3096968a91.37.1771003341122; Fri, 13 Feb 2026 09:22:21 -0800 (PST) Received: from roxy ([2a09:bac5:40b5:1aaa::2a8:23]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35662fac3c1sm12572425a91.17.2026.02.13.09.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 09:22:20 -0800 (PST) Date: Fri, 13 Feb 2026 22:52:12 +0530 From: Varun R Mallya To: Yonghong Song Cc: andrii@kernel.org, alan.maguire@oracle.com, ast@kernel.org, daniel@iogearbox.net, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH bpf-next 1/1] libbpf: Auto-upgrade uprobes to multi-uprobes when supported Message-ID: References: <20260212152013.17351-1-varunrmallya@gmail.com> <20260212152013.17351-2-varunrmallya@gmail.com> <82d31503-24d8-45b8-b1dd-2cb35bd28509@linux.dev> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <82d31503-24d8-45b8-b1dd-2cb35bd28509@linux.dev> On Thu, Feb 12, 2026 at 04:06:22PM -0800, Yonghong Song wrote: > > > On 2/12/26 7:20 AM, Varun R Mallya wrote: > > This patch modifies libbpf to automatically "upgrade" standard > > SEC("uprobe") and SEC("uretprobe") programs to use the multi-uprobe > > infrastructure (BPF_TRACE_UPROBE_MULTI) at load time if the kernel > > supports it, making them compatible with BPF tokens. > > > > To maintain backward compatibility and handle rare cases where singular > > uprobes are required, new SEC("uprobe.single") and SEC("uretprobe.single") > > section types are introduced. These force libbpf to use the legacy > > perf_event_open() attachment path. > > Maybe you can have bpf programs for both uprobe/uretprobe > and uprobe.multi/uretprobe.multi? > > You can add "?" before the section name (e.g., SEC("?uprobe") so you can > selectively enable those programs before loading. This one if one choice > e.g. uprobe/uretprobe is not working, you can then try > uprobe.multi/uretprobe.multi. This is a good idea, but isn't making the upgradation built-in a better choice ? This way, anyone writing the program does not have to rewrite the same thing twice, keeping their programs pretty clean. This also moves the upgradation logic (which is probably going to be repeated multiple times) into the library which makes it easier for anyone to have something BPF Token compatible without having to write all this extra logic. Since "uprobe.multi" is compatible with "uprobe", I don't think anything will break as well. (The current breakages in the selftests are due to the patch being in nascent stages and I'll fix it after I get some feedback on my questions.)