From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (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 BE767403144 for ; Fri, 12 Jun 2026 17:04:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781283860; cv=none; b=Ycdw/aLmXbuFWVF1sWC67KqPulUlif8fiEt0nEmDLgodLkmPnuS8vMhsJ7RL+7DPAjS2G0kK2os6onH6HTnj6XF3PgbBAwSbeN15Oyb/srRvr4EMpLJUQHKXzKargOpph3xHNTFUz4+L+olKNHCkZabZMRSwiashyO6wUf2+1Ec= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781283860; c=relaxed/simple; bh=x7JBV1YxVrPj4/1vBdgzqqKO1DpryrChHhSxeL1cbvA=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=EcL37rxZLtzOI8zbCoFf9QcVHJL3BSr+3p/fsXctqaaeeZnzAeDxTOf87tnzI4SWiT3zmEOrpVcqJUZWpLysvPBzYsi9WeDxuUfSjrXPMIaP04cpOpsblhdpnw2y19boFDVNvCdCqTAKB9Ob5eZiJF3U3hVT4T0wzIcCrJQ6scQ= 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=h0XmpJfB; arc=none smtp.client-ip=209.85.167.180 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="h0XmpJfB" Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-4864a5c83f1so944766b6e.0 for ; Fri, 12 Jun 2026 10:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781283858; x=1781888658; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O+CzGFIuAycc3JTH3gFYPgt2Y0prLl/gqutaLhPH2tg=; b=h0XmpJfBN3aA8/I9MeOh7mZ22rIraPMCUXRe6Uo+/kmLDnY9rZbBQMd568HZA4h3ZQ gsbgQTr1ZOzAtsFlwOoeLGnJWH6s5sVqlCui/ppWHwNXmded1gzYe18b6n1ZkkjrsTay +8vWO01kLZCQk4QMFMae6yrQtiLSPg5vMOJ9QItqfoUxtoEMb430ANmT7CWRCtW7czJP EnjYHStfTfrmHOUUfMnKsZ9jHlCpUV3QX0DPhbceYjLSztdE4KUjdCSx9tIJdyEagyua hDl3djBwg5mRxvlSvSnk2gh+w3RuCKIi7bRW7FlM+BB4ZfoadunexQWEkMy64bKkT2+y JX+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781283858; x=1781888658; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=O+CzGFIuAycc3JTH3gFYPgt2Y0prLl/gqutaLhPH2tg=; b=QfYGplOvs0VjS71ELKaGgkFfJ1IEqsDWHmzLN0ledDSYozbPoT6usB0m5G8kuaSHNb +qWc4aPtuI3O0pqOyO7K+VSqWPo9eYaOSGftgehthuvNeILycGub+Hvchn5wCEnGDhQR kBl+yyv99eZxPmuLmXwn46Xu6kz1ktiepBYorJQVehtoEYHfXeIU5IG6HPBxesa41QaR ISAo1a4Z/hxge2dvi/5cS5HQwQGJGiThBHVIwGdWzI0tlB4NolIB8ZKSt3WCtvEgyAg7 eZiiDfuamtk7sK7hlhkZpYKjXvDp2BeIsY+1yY0ASAhb1DFEYNWDBvgcMeWs0jLWDdlj zRUQ== X-Forwarded-Encrypted: i=1; AFNElJ9jWqkiqKBwNBN5q68HVrz+drZS2G3GYWn1ls8opEVKHl/svJMuLD/Bydv8WO4sBP4sLPA4PM6snTQ5F6M=@vger.kernel.org X-Gm-Message-State: AOJu0YzwsRSANlIIaYzkgaFpPAb+w9A6B5+tSgEfwi3jcPM7Hl00Ra3C k+hz0xGFEk+PSjT8D5Avo92hrslrKfeQ3AUtgx0mhlzeqMO0brGyxDm5 X-Gm-Gg: Acq92OFddksoiln6YxAy8+Bb+L08UvrQ97raYZdyHFMo+G1GHALmt78kUBFP+3Q1iC9 BuP/rxJ8MddKZcly4oo61DQhmZiLa/dr8KULfjaUZL4hglMkwDGb/RUJsmhoHkw5PV2l0WK4sRB nKD42G6clf2Ajjz1GuGSN7ZuMiUdHFExAhFfj3snqrQj6Wznl7Ncq90cM4QyDATHm7CyauIMrKw EhT06+wJ3ApEBL+pw/fSviOLF2zOI3aNcFkgSmo3wTpo9xs/hnNofq123jPOBhCZqC/e8z10njX ds5CqF8Sy3mNsMbedGakFeb38Wn/pzRecfIFEFGoVTiucH2hzndrezr6/WZPlcCN06RWLIvDtRX pFucQCJk5Yw1AdGXb1eTcgDGXywief7tof0LuE+Wh9OqvFD6eh5f3alWO9PlwQMvta+OgR4U2dk XFZX9od1/F8ZdmbRXfNeEvykQ+cwVWcL1WS87ZjuIngHqMkJKU/KVoFbOkRHRikDNUNpXFjO9HU ew8B/tXpYvSoJZwkw== X-Received: by 2002:a05:6808:c413:b0:486:a606:c6b5 with SMTP id 5614622812f47-4872f50eab1mr2764073b6e.23.1781283857489; Fri, 12 Jun 2026 10:04:17 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:18::]) by smtp.gmail.com with ESMTPSA id 5614622812f47-487313bcf8asm1337937b6e.2.2026.06.12.10.04.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2026 10:04:16 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 12 Jun 2026 10:04:15 -0700 Message-Id: Cc: "Zhenzhong Wu" , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest From: "Alexei Starovoitov" To: "Shung-Hsi Yu" X-Mailer: aerc References: <20260611160749.391279-1-jt26wzz@gmail.com> In-Reply-To: On Fri Jun 12, 2026 at 3:18 AM PDT, Shung-Hsi Yu wrote: > On Thu, Jun 11, 2026 at 09:55:55AM -0700, Alexei Starovoitov wrote: >> On Thu Jun 11, 2026 at 9:07 AM PDT, Zhenzhong Wu wrote: >> > Add a verifier runtime test for a branch pattern where a helper return >> > value and a related scalar stay live across the same control-flow >> > sequence. Rust/Aya-generated eBPF can naturally produce this shape whe= n >> > a match on a helper status keeps data derived before the helper call >> > live across the same branches. Such code commonly uses the helper retu= rn >> > value in r0, where 0 means success, producing an r0 =3D=3D 0 / r0 !=3D= 0 >> > branch shape. > [...] >> > +SEC("tc") >> > +__description("helper retval linked scalar pruning") >> > +__success __retval(0) >> > +__naked void helper_retval_linked_scalar_pruning(void) >> > +{ >> > + asm volatile ( >> > + "r7 =3D *(u32 *)(r1 + %[__sk_buff_data_end]);" >> > + "r5 =3D *(u32 *)(r1 + %[__sk_buff_data]);" >> > + "r7 -=3D r5;" >> > + "r2 =3D 0;" >> > + "r3 =3D r10;" >> > + "r3 +=3D -8;" >> > + "r4 =3D 1;" >> > + "call %[bpf_skb_load_bytes];" >> > + "r0 +=3D 1;" >> > + "r6 =3D 1;" >> > + /* success path keeps r7 independent; failure path links r7 to r0. *= / >> > + "if r0 =3D=3D 1 goto l0_%=3D;" >>=20 >> this exercises linked registers with BPF_ADD_CONST logic. >> We already have such tests. Why do we need this one? >> How is it different? > > BPF_ADD_CONST wasn't what was meant to be tested. > > The main logic is r7.id =3D=3D r0.id only happens on "if r0 =3D=3D 1 goto= l0_%=3D" > fall through, and does not have such link otherwise. I only check tests > added in commit c0087d59e504 ("selftests/bpf: tests for per-insn > sync_linked_regs() precision tracking"), but it doesn't seem like such > conditional linking was tested.=20 > > The other rational is that this seem like a common pattern that is > genereated from Rust-based BPF program. > >> > + /* success path keeps r7 independent; failure path links r7 to r0. *= / >> > + "if r0 =3D=3D 1 goto l0_%=3D;" >> > + "r7 =3D r0;" > ^^^^^^^ conditional scalar linking Fine, it's a regular register linking without BPF_ADD_CONST. Still the question remains. I believe: "We already have such tests. Why do we need this one? How is it different?"