From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DE5926AAAB for ; Sat, 14 Feb 2026 05:25:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771046741; cv=none; b=R5UPRv3Wmuj2NyPcrMg7wl2rDhTi4V55a0NdBzlyEH+pdAhzwEdJYmVzMfYRIep+SV89c8H51HwPdoR3vgU/IvEnXrLiVItdNG1/trJiJ1n6lboZM3HdBQRnx2mtFpE55y7D17nc3KER2AkrFAgrzJUa4V4/Ku7qG0K4TPOeoEg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771046741; c=relaxed/simple; bh=wcUoxwPfT1Uw/weaHYkjd+h6xf8NBJfe451UDd3hvSU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UbfxbZ0T8bYXG2JIjEoC2Dy1CZ2/K4d5nj+yKj1fCJjUrsHyFRAgjpWCSAwZTYXyGG6elYlWxinr9FauzsqxOkWz46JzgAZtZKjsc1hbtrm/8BZnoOekevOqd9N2Br5sFlNcei55R1zsf8yGa5wjUzWnz1IpCdtR+5ogSEGfs9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=xY4F8Zkn; arc=none smtp.client-ip=91.218.175.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="xY4F8Zkn" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1771046737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wcUoxwPfT1Uw/weaHYkjd+h6xf8NBJfe451UDd3hvSU=; b=xY4F8ZknEXem5unamh0KOuxDLkw1wkSioBIZexZ/T88NdgdXwVfMel1ATrdwtCE3l/JY/C OywGd7awdq058fUUJBOGqgT6HJIKSXrydkCPcPM499I7dRHhjDpy6M5ewIF1nufKFL6enG 9/KHzf+q4izG2PeJmX7mugWe7TZIDhk= Date: Fri, 13 Feb 2026 21:25:30 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC PATCH bpf-next 1/1] libbpf: Auto-upgrade uprobes to multi-uprobes when supported Content-Language: en-GB To: Varun R Mallya Cc: andrii@kernel.org, alan.maguire@oracle.com, ast@kernel.org, daniel@iogearbox.net, bpf@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260212152013.17351-1-varunrmallya@gmail.com> <20260212152013.17351-2-varunrmallya@gmail.com> <82d31503-24d8-45b8-b1dd-2cb35bd28509@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2/13/26 9:22 AM, Varun R Mallya wrote: > 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.) I still feel this is a hack, esp. for libbpf. The libbpf provides various APIs as the building block. Automatic upgrading inside libbpf does not sound right. These upgrading thing should happen in applications. From bpf program side, you can have progs for both uprobe and uprobe_multi. You can have static function which can be used for both uprobe and uprobe_multi. It should not be hard. Looks at bpf selftest, there are quite some programs with prefix "?" which gives application a choice whether it should be enabled or not during to kernel probing or other things.