From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 D2D473AF65F for ; Wed, 1 Apr 2026 10:53:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775040798; cv=none; b=C2I4Dl5pzwcjm0IrBCc5PnYe8nrFVYJgdrxaohiEOBKuZKhTASPwE5ylSAcU8YlVU4sf6Lo6S6Z4QSNrLRaFMGaMQcUSWxBw4alM/E839yXTdOaU3mE9faOxP9OVnZ03O6bGSPCyl/xPnH0MxkhErTrVEucG+OaJLcAyCU/ijOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775040798; c=relaxed/simple; bh=UvyDyyW62o/2RLTvRuroInPpDO903kx2ZQTtjJhdI6M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Kf3gWhq75Yf3NxKJt3mHD6KEF5aoq5FZRLIUR74qEDi7MqWrCGl8sB0wZIz4DVP1bfUUc2J9b8YpcFIOorD87Jc/HXuXbQCgsCxuC1mpgkUHdUitIjw8nFk9PeQ6F1Wn64kbfZ4xLv9fjmVu89FODng3Cs7fnen3rf9soIMVL4I= 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=SD3yVIJJ; arc=none smtp.client-ip=209.85.216.42 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="SD3yVIJJ" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-3585ec417f6so302255a91.1 for ; Wed, 01 Apr 2026 03:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775040795; x=1775645595; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=b1cDM+9ZaY5XHKgHPK9aHCTW+oushVX4JCMP/tcbrFk=; b=SD3yVIJJf0Sgm9U36qdaIqSS3c/cMm7jSpb+SgVWA4/b34k5JAmIju8dCukubX2AFa 5JgriHmLpDsAyWnxuudAIGwQwuHe0N8juLC4a0aUIQpwpKOCIYZsQKgEj5TO7YDrVeou qiDxu8Q8G1a75w2+P67ZQlF3RBSIPuJQIYxlG3wA05CYtW0oYhhxeOVfGkDMEFj6ggNl WFTIhkl57vUIKMAr6UUXirFDh3MMhsOj/w+CR8se3nup9CpmNRXlcb8181bMymmuUARk GLRIpQYEbqe1jVkyiJYnN4IR5DBHjOp/f5Fofnx9eHsASRyu63PbTL9dqLTkN1j2w8cY RyrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775040795; x=1775645595; h=in-reply-to: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=b1cDM+9ZaY5XHKgHPK9aHCTW+oushVX4JCMP/tcbrFk=; b=PylPiHdkCNy0iUGNA+mfOdF1tBd0oS0PwSC3VXUmb/OzZisEW2T7NJxTbARhu3kjet pS28L0DGSVxE3nTIdeaqTGllmGdKD+VSz/xgsUyfg0bdqsh7JRCmSXaX3N5wmxIg8L53 xrzsPY/tk3NWdUP+ndycJRt4lt35y3toiff+/zOJfPcC5WwM/+wLNGw3Pi7W8y1RpGzH yuu3FlaofloViGYvJVzCMgmZfdXFEFUr5KQCLmsCv3/UEK/yNy1pAG2D9VB0aAB+GfA7 tMqTwJjsMuNYCjjNfdvCzA+vskJ1JVIqFiecj6BcNO5btlI+GYAc+FJuku6MHVepU4G2 jpZA== X-Forwarded-Encrypted: i=1; AJvYcCX68A/vq1xXXKNWRaxpQN33YaGKvwESaAUqFFoYLgeFwBc5XL8wJJdyNfjjoyOx4IKEIsr2XAvSZjIfADA=@vger.kernel.org X-Gm-Message-State: AOJu0Yy3zyRGc5q9NA0XRquTjYlWScrm/HaL+DzUcWJYEbMKeqs3v82Q ysexppHqE/YYTcgquJxSQweeZuQ2e+uZq3XqcPBiARkWXO6F1/97A7YU X-Gm-Gg: ATEYQzxPZFnz3RBclL08+RDTw3n4Z2M6k5VifNPJ/hMNW15vwrejhik3bo5/hxdpwJR t8SVeItoXIPUdShkqD5Sz0GzEcT4JVfGw3wBD6vAWFLCA2fciPMV9BMzCI//kbwSry2ykJBNgBj 3DpKTZDCqScqDVpkpdq+v+AdMqjZKjLmVCnbjTrTi4eBkWSOjUMTUpXBUZAU9DmPiv7AGuNmCaY I8eynbjWYULBuYPkQR2Qnfh0+HFFDkCK880GGD4XZPGp+6sEGIrkWV+G++Fhmd4/C6Adx0fRLL+ mVbS2CKdDOFGrnPBydYuJhY7huxp5i2jJlrPyuJJTcS//wSTwpuVrID+mHB/sy/OB8gns/Kav6V 0xf6iQiMO8+SpdbyXoicAL4Agxq5A0LYV9TbAcMgIfGgcG8VmBtnaXHZTk9A0NVhXRbu4sxdoOz 32sxFbD3jZx2d4SEOUYKcTsKHAK9F2Q0UxhewMjUuR X-Received: by 2002:a17:903:124c:b0:2b2:53f5:461f with SMTP id d9443c01a7336-2b25ef9ece3mr65034055ad.25.1775040794851; Wed, 01 Apr 2026 03:53:14 -0700 (PDT) Received: from computer ([2a09:bac5:40b2:a82::10c:35]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b24265aa9fsm138622335ad.20.2026.04.01.03.53.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2026 03:53:14 -0700 (PDT) Date: Wed, 1 Apr 2026 16:23:03 +0530 From: Varun R Mallya To: Jiri Olsa 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=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Mar 30, 2026 at 04:53:38PM +0200, Jiri Olsa wrote: > On Mon, Mar 30, 2026 at 04:30:19PM +0530, Varun R Mallya wrote: > > + 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? Thanks for catching that! Removed. > > + (sec_name[9] == '/' || sec_name[9] == '\0'))) && > > + !strchr(sec_name, '@') && > > + !strchr( sec_name, '+') && > > + !(prog->prog_flags & BPF_F_SLEEPABLE)) > > is this check necessary? I had to add that check because selftests/bpf/prog_tests/attach_probe.c was failing. Sleepable kprobes are not supposed to attach successfully, but since this was upgraded to multi, it was doing so. So, I had to stop all sleepable kprobes from being upgraded to maintain compatibility. I'd like to know if kprobe_multi is even allowed to be sleepable. I could not really find any selftests or patches for sleepable kprobe_multi functionality anywhere, so I just want to check if this is not actually intended behaviour and we are missing a check somewhere. > > + 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) I am thinking of making the return type void though. I see that there is int everywhere else, but it does not make sense to me to return an int here since I'm not doing any operation in here that could return an error. Should I keep it as int or make it void ?? > > > 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 Implemented.