From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (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 10386238D52 for ; Thu, 11 Jun 2026 16:55:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781196960; cv=none; b=oHMDIUqBXzRmrepLBdtHLFKjX89ZFtrc2Vn8uJM3niFKu1YrjwrQtCsKIEjhRruAX9duHreDoQN/UmSWwhOFAzC6YazP91Z9n7En7pCa8T6Bif8aCOyfbWsIiFO/FJCuQR23NOIAL2/JXg8IZdASI9yBF78cQaFW/L0K+5LE4r8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781196960; c=relaxed/simple; bh=T6g7rg3VitWcivV7EeuR9/yu2am9emv7c3wvIiILvEA=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=iNCUimlBlgjv3Ru/v9uD9nKFaOOibE65fDqJ8fYb6oqRb2/DFt5d73ZtTn4v25Ak2zgeVYfNMaqiPX/UYJ/6Vp28f3NFSI1nrS5jHE6fjGRBCgo9HKOM79xcGcxsZkcBLykgktb29gte3FaoppO7piCYcPweBVMpVQUhJwkFsQE= 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=RrUnnujf; arc=none smtp.client-ip=209.85.210.43 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="RrUnnujf" Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-7e6f27619e7so72485a34.2 for ; Thu, 11 Jun 2026 09:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781196957; x=1781801757; 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=Fh9XW+WhkgIww8VbLUN7r2hGLoFdTbeh596jB8sD3f8=; b=RrUnnujfxy00+c8g0X3L+FmekhiBn1M/EKVeBtewSm6yEa7uQvLWyRmLZuD0xfqbYn 0cDT7LicQCJJa/Zi6im+5xgF8fTQL3qVHl0mHYTmsM772KfVUSkcQi3DAqx4F391xC0Q vBX/LhpnlttN8XBXYIsT0OTHg0HWKZLqDz1nzjTOiV9m446+viAhbJx/HOP+DH+lkRy4 jV1Yx7HOxTvnQMXFMdWIZ4Jn/XjZN7QQm0331U23FqGvTixU7HyaHmMGoHstkSddo6kM MfmwEpfL+6ODeWEvBpbjYyBcDFYu0iyTocjeY26znnSj69ZSDEXw3b0T7k1ARVJ4/L9L AP1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781196957; x=1781801757; 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=Fh9XW+WhkgIww8VbLUN7r2hGLoFdTbeh596jB8sD3f8=; b=C+jDk/QThR82YqGM9AXkB0kxNHquoPqn877F6c1VMgekUvDBtCLACk2AZ8nG52/IWG 2YHehbEhfEIk3bUtpFFeMfDhimQFkWcmaZli0w7dmKuz8yLf1CuI3N1TILPI3OdLsp40 BbBoSqxDVXXsv/JalFth7MbrNxEEopoLKTeV3EkypOm0p4nHNzj6JOC7prdJ2haHw0fd 4hEKx9WFuHUo23I5eJ8q2ODJW3O5oerKjI0dAfgT1TcXHxR7QfOY4pnM6YEveP2M9Hdx 6ddNz2DC2e6HbcYJByGu5vm7laIgXRkqbgFYG/O7QbGLOQpI8yVePTRoOxVoEZFlEh8a IK1Q== X-Forwarded-Encrypted: i=1; AFNElJ9Kw/1hk91GErcHLTU0GqlP6ZgptLSqWvR+8llGb7KBlgWEuZ36kWAWGJ2y+s6MzUwH7SI/wL3S580Rl6Y=@vger.kernel.org X-Gm-Message-State: AOJu0YwPcScCN7AmB2lqbTpDqr8ok8vdpLpUS1MwXSBNfrC5Rb9E2Vv1 +gX+xBSW8o6gcLCedUN3IC/OcAoLmxl6xRRnjyUR1509CvjEXf727N4o X-Gm-Gg: Acq92OHG2tvE3BNpFtSvAyoeljtfJQJ8u7a3bR1ezQA2kZH+5g3mJMcSFoyILjeXcBt DRRCZdkPRg1dtqfVv66G5HMM39EThT2pWUiC9x/bP3WUnIyX8F0SSRQKslw6+Jy9WNt8BqCCCE8 FoAyoWFaOik0g1H4U9Fuh4JPP+Igkz1qexXdjDolb8x/POecZvtMvKhV9r0l3rHwdedv2Hb0X/o 2iX2D89xSQkZ7s+lgwIKtaFAjMeTX/2IfpjAEcpnSAHuF6sUl9MsK8ppe9njaszHu2dSBrAAA7U xuydy8i6HeuTkcUUoY1LbGazDFc/Lg0ezNmKNWZCMW0XG+m+MndeLE/JsK9bA1/2UJtWAOR4Wvg jpYHImWL3W7JKPx1lqVo09GWUZwOdLpyI9TJ4ZTkc3YsDp3N+sq7SMFAM+MweEpMlfQzkYrxFhF RN3kZBEGlUG7kxIOL37CruHv/op8I2J0Y026DqhFMKjfPY2Asm/LKSqYPmpr0bsFNfLLYP2d5dL TdPKJq5dT0TSjiskw== X-Received: by 2002:a05:6830:6885:b0:7d7:d524:bc88 with SMTP id 46e09a7af769-7e7735278camr2782858a34.10.1781196956889; Thu, 11 Jun 2026 09:55:56 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:47::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e774cee36fsm1748641a34.22.2026.06.11.09.55.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2026 09:55:56 -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: Thu, 11 Jun 2026 09:55:55 -0700 Message-Id: Cc: , , , , , , , , , , , , , , , , , Subject: Re: [PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest From: "Alexei Starovoitov" To: "Zhenzhong Wu" , X-Mailer: aerc References: <20260611160749.391279-1-jt26wzz@gmail.com> In-Reply-To: <20260611160749.391279-1-jt26wzz@gmail.com> 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 when > a match on a helper status keeps data derived before the helper call > live across the same branches. Such code commonly uses the helper return > value in r0, where 0 means success, producing an r0 =3D=3D 0 / r0 !=3D 0 > branch shape. > > The test preserves that branch shape but shifts the success value to 1 > before branching. Using r0 =3D=3D 1 / r0 !=3D 1 avoids depending on the > verifier's not-equal-zero refinement, so the test exercises linked > scalar precision and pruning behavior directly instead of being masked > by zero-specific range refinement. > > On affected kernels the verifier can explore an impossible path where > r0 and r7 are linked by scalar ID, keep the wrong branch, and make the > test return 1. With linked scalar precision tracked per instruction, > state pruning keeps the real success path, and the test returns 0. > > Suggested-by: Shung-Hsi Yu > Signed-off-by: Zhenzhong Wu > --- > .../selftests/bpf/progs/verifier_scalar_ids.c | 35 +++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c b/to= ols/testing/selftests/bpf/progs/verifier_scalar_ids.c > index 70ae14d60..de71d547f 100644 > --- a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c > +++ b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c > @@ -448,6 +448,41 @@ __naked void linked_regs_broken_link_2(void) > : __clobber_all); > } > =20 > +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;" this exercises linked registers with BPF_ADD_CONST logic. We already have such tests. Why do we need this one? How is it different? pw-bot: cr