From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f12.google.com (mail-pj2-f12.google.com [74.125.227.140]) (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 E38864F473D for ; Mon, 21 Sep 2026 18:59:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.140 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790017162; cv=none; b=N5izzUEyZ0u3SdStYqmoZ2f3ZdnhcONHAhaj3lJ9vePp4y7iUiUiVNvpeSElXN9cZDKkmCQykBHhTFaYpJL0QQglUnKaJMBEIPZktx79ZyXkF8g/wgDC7+JGplyqU72p6rJFOchRJmICPhEPK086nOSSvshHdeVqwGnV8evPWiU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790017162; c=relaxed/simple; bh=YnyvAjF56sMlW0OrPQrd2ZaEK0kUPzuONswa+SYLl8g=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=NzONO5LLr5BLfwhQDp6grBqg6DGfMiso3PxZKoNawCD/vb9tmjYIVXjCSiCFPcCbpd4LkI3DBis2KyfXFqNrAUTX0P7yyeNJGEUSAaOu2ekkZYLQSKM+ZROILNF+KXvFeD9WsKu8yddtb0WirWH9Fni3VfygjWCBJcOKkWmX7uk= 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=aiKaX7GO; arc=none smtp.client-ip=74.125.227.140 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="aiKaX7GO" Received: by mail-pj2-f12.google.com with SMTP id d9443c01a7336-2d747f01363so27455225ad.2 for ; Mon, 21 Sep 2026 11:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790017160; x=1790621960; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=UerVz0NFlQQ3lB7m/y4z+RXJf80VJxp8tkbVGLZEVEo=; b=aiKaX7GO7H30r+xmDq0tFH8ytRtwJHm0Erkx5xvHYGUEVQwUgtOKBhF34jowuBLuWs RpyZShBYg/9EKZ+NG/5+MRfqMTwWNsTAkeb+ul2oKmKY5zpoDCq1hZEnbean4C2bV4ZN ENRtktK2qKpOQbtQE0Wn9TUA45D8WzDztjE6NQsn+ruxGnx3ncoorHb63R2oSjE0mZOf ewOJIyVZb6L/Q0xm8fUvpE044m2XyYjo8YEAPv0TYd2hlNd9tlD4XMnDa/YzdMl2OB3P q6zOPAnyBjDRiJ/FcFAQ9jDXhvi5qhJ0gVzRBOOl4mjeAbjBYMsk9SuaRWg2REB4EVx2 VsEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790017160; x=1790621960; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=UerVz0NFlQQ3lB7m/y4z+RXJf80VJxp8tkbVGLZEVEo=; b=EfyO+aumg+84ya7b80eczMAwcXQfvC8ozkR62sLS0ceclGc/vMfQS2WLkxjw+1cujC ZMQQBUeFiaNVTJgW2ZHMOKR7VszZP++ZSxdINqDbpp0Khd+1wSHdiCNRvvgqt2XKiE26 IOib63SZwSzBkEJlgHfxDlViJYfJFEqc2YYBiyzKMRrqc0yqaux7i3z/JOJiSFO+OZal iSa850V8XA23/XxrHqT3j8mHqSefhafkR8g9I986M2tRkY7z592Zbibk40vSa1hWmF6j hzrpHoCZyGWnYNFSXYcnKRMR2ExVZ6dA/mDMl1F9f3dL3q9HQgAIo8ZSTAEdr2yYGIpD SWiA== X-Forwarded-Encrypted: i=1; AKwUvBz6Uk0FQ1Ni6pFmb4QrN7fdq29hP3d9Lx2p/onH/hIUXRdGp4wPcFswTcKAlQlHz4RLFcx214k4fAcncqTQnUI=@vger.kernel.org X-Gm-Message-State: AFuF++nY4G2P+eEwx1SYTkpMLwFvooc8d/UM+Go4VhU6uOb5fXmQk6pB RmIvbFyD9ChgBGmplJ6J8Ep0OXkYxEM2wKlS9myEP5jpTpihWg1+fd65 X-Gm-Gg: AYBFou2JS4mgl4ijLQWSkArRwqznSKQ5o78hOC2uhsKCF+7M82W62wbFOkkKSml9Zkx Bu87O3SLSdyYBA1T4za+0H9CgYWWySb46vnoiYHy9Fb63TPYy47yfMx8rb/CAZXxEJL/e7RVCmR YNdWoUTSwgIFqiENqGCinFoU1vWGyaWCVjdQ5psGp+uLWbZFK/cHBdeErqO0D2AlxKCwEjrOxNP luXgQYBJBOl2/YeiSfOO1L+BDKJNlbXjFZqeJQC7CWpR8IydhNhYJ1xTLCyFXvUJJRvK/K32JkA 9/rh/9cciPMEGK0Zr5MmqRcXtzLw5kD4P1WfJ+FU5SQW1f0X+yeQ2DYKNkDN6kLvnHkuWtiqK/V 0f5pwthUYBT7KTsWc+YdyAOzd+Bf+NgNYGa9WdDpshOaVJATNJ1EuLODdwxngvxGsHMvKuKpdRk Xi50Gadp2qg0NaJME0yhjAsuDVTSyCZv4K6OzJn1b8D7pw5XvvJDziqbsEESitRbxv+tsl97y3h wPm8bf46/M0ikBVleXhnzqfWKNxSftXSXHv2xXgjur66F6NJ3+5Ec2salq60wQSai09oqxOa2v8 5v0= X-Received: by 2002:a17:903:1b08:b0:2dd:c100:9440 with SMTP id d9443c01a7336-2ddc1009c6bmr112993325ad.62.1790017160092; Mon, 21 Sep 2026 11:59:20 -0700 (PDT) Received: from localhost ([153.61.198.252]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2df3c2acf1csm28063935ad.32.2026.09.21.11.59.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 11:59:19 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kselftest@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: Mon, 21 Sep 2026 18:59:19 +0000 Message-Id: Cc: "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Kumar Kartikeya Dwivedi" , "Martin KaFai Lau" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Emil Tsalapatis" , "Ihor Solodrai" , "John Fastabend" , "Shuah Khan" , "bpf" , "LKML" , "open list:KERNEL SELFTEST FRAMEWORK" Subject: Re: [PATCH bpf-next v2 03/13] bpf: track low-32 scalar equality across zero-extending movs From: "Alexei Starovoitov" To: "Eduard Zingerman" , "Vineet Gupta" X-Mailer: aerc 0.17.0 References: <20260910164635.459558-1-vineet.gupta@linux.dev> <20260910164635.459558-4-vineet.gupta@linux.dev> <4ab75099-0e95-4fee-81da-6f4198e3e6a0@linux.dev> <202c45e2-58ba-4ad5-a234-c90703031f91@linux.dev> In-Reply-To: On Mon Sep 21, 2026 at 5:28 PM UTC, Eduard Zingerman wrote: > On Wed, 2026-09-16 at 17:30 -0700, Alexei Starovoitov wrote: > > On Wed, Sep 16, 2026 at 5:08=E2=80=AFPM Vineet Gupta wrote: > > >=20 > > > It ended up with full testsuite run parity - after 4 incremental patc= hes. > > > But the pattern of all those patches was adding some predicate / > > > special-casing to reg->add_const > > >=20 > > > hunk 1 > > >=20 > > > - if (src_reg->add_const) > > > + if (src_reg->add_const && src_reg->delta) > >=20 > > why? It should not. > > My point is that zero is not special. > > It should be handled within the current framework. > > All these extra hunks are not correct. > > ADD_CONST_32 logic should work for delta =3D=3D 0 just like > > it works for delta =3D=3D 1. > > After thinking about it some more, I agree that having an orthogonal > encoding would be nice. However, it appears that the split should be > somewhat different: > > struct bpf_reg_state { > ... > s32 delta; > u32 id; > enum id_link_kind { full, zext, sext } link_kind; > ... > } > > Where: > - id =3D=3D 0 =3D> no id link > - full =3D> all 64-bits of the register are identical to > all 64-bits of a scalar value `id' (let's call it X). > =E2=88=80 rA{.id =3D=3D X, .link =3D=3D full}, rB{X,full} =3D> = rA =3D=3D rB > - zext =3D> lower 32-bits of the register are identical to > lower 32-bits of a scalar value X, > upper 32-bits of the register are null. > =E2=88=80 rA{.id =3D=3D X, .link =3D=3D ?}, rB{X,zext} =3D> rA = % 32 =3D=3D rB % 32 > - sext =3D> lower 32-bits of the register are identical to > lower 32-bits of a scalar value X, > upper 32-bits of the register are either 0 or 1, > depending on the bit 31 value. > =E2=88=80 rA{.id =3D=3D X, .link =3D=3D ?}, rB{X,sext} =3D> sex= t(rA % 32) =3D=3D sext(rB % 32) hmm. there is also 32-bit link with delta, right? > The reason for such subdivision is that: > > (X + delta) % 32 =3D=3D X % 32 + delta % 32 =3D=3D X % 32 + delta iff d= elta < 2^32 > > Meaning that a non-zero delta can still be used to infer the state of > the lower 32-bits, e.g.: > - if r1 =3D (X + delta) % 32 > - and r2 =3D X > - and there is a comparison `if r1 < 42 goto ...` > > This comparison adds constraints on lower bits of r1, > and it is correct to transfer these constraints to lower bits of r2 > by subtracting delta from r1 and using lower bits of the result. Not sure what you're arguing about. My only point is that 32-bit link with delta makes special handling of zext unnecessary. I still don't hear a strong reason why it needs to be handled outside of 32-bit-link-with-delta.