From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pz2-f12.google.com (mail-pz2-f12.google.com [74.125.228.12]) (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 2BEFF395D9F for ; Mon, 21 Sep 2026 19:27:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790018859; cv=none; b=k0nwRWphFWFtRc3bPV37JpDuzPJ0BgQVbzq/hKn5A50vy7XXR11Qc4VDnDDMHLXwCYNOtU9SN/7Wc8g9RSMf5bDezJxAZ7CKrUYh5BKWCKFUhK06Rt4Nfu2J6PRXFubGZl4aViythvlWPL2b/fqZV9Z8Xv9VyxnHNu/Mmk2KzAg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790018859; c=relaxed/simple; bh=4on2XQCCKq79/vtxCsDoimfudfbqBXEbuHawU+G11pc=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=LpV5Bft04fKLGkU+h/1xBIvEF4BfXjHh37c9bFiyCVzsXoxd2HDx9la6e6OGluDIgKQdxGQLxCZ/0CO+nkO+D7mXOoyWrCnpo62jGqIwey1tEqhP8jkv0e4Ux+Uf+QaS3qu7Uks8avBKt5IsVj/4BcHkAOpItNoPtyM7214K71E= 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=ZPE4PbSz; arc=none smtp.client-ip=74.125.228.12 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="ZPE4PbSz" Received: by mail-pz2-f12.google.com with SMTP id d2e1a72fcca58-85469b2e1d5so3471269b3a.1 for ; Mon, 21 Sep 2026 12:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790018857; x=1790623657; darn=vger.kernel.org; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=+BuFRYJQioQsFKMrRoqK+vwHlNR8DMCln0kaU+pU5wk=; b=ZPE4PbSzVro93qo/gQkB40ESIYppDzFxJ9Cw5xxWAKZM0D1yeCeDAqezL5ns6dBxjy uZWUuijflIdYXihjLrA+VYfPfEXMnUwYj8fIDZ8qvH/WjdJoD9tLcCppsvKnV0CUCpEQ ciadN17WT/ntmg2CaPXiZ8cIS6RQHs2LJiAVXgFlmBciSDmjvY77pMMpHjAOYufxYGIx FcOfp+msRxwYIuMfIKT+RnEBVkpn16wA9WxH6uuWy9HLAsZHtSW8Vxe4ohdtKzASxu+z hQiE/wqhlPJKCMM7POOcwe5F/iXkigSuunZk3b+2KYmzsYsWXC0jMvXQCVrX/QAE4s9K Ns2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790018857; x=1790623657; h=in-reply-to:references:from:subject:cc:to: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=+BuFRYJQioQsFKMrRoqK+vwHlNR8DMCln0kaU+pU5wk=; b=DWDjkzTXqWGZolf2eB+28vnzSGU8O0EaR0FILeY1KpIlTRDyLmf/H2ybLf5Tz2OngB aS+m3wQopHnTRqp2PzUXQ93tMeG+KpXDN4kElUxEVWMy9KMfm7sHYZPDaJGO1HYBEV6F iC4QqcsSUm+kw3HLaytzNEfOAfM1o05fHHRusRJrFt1k0VDKguJuSjtWDxaJx18QnurD Emi7pceGcLJURjvSpz8i+TrKSX5iztvy/kM1hqRL26nj071UJkDR+BRuB6EzC5qlCN/b b2TKBScNt2PBVUYfiAPBuuKuK1aGpJbs+1td1sOQ6bOgv8+1KJAHYs3kI8U0+H8WOcxL DmQQ== X-Forwarded-Encrypted: i=1; AKwUvBykvIZRFY7slKT1hHM42IR2g+97lrz6Go4B9OABuJD7Dn11SiSi3jxOVVFqhgeOg2UylLaLjuSvIDEAcRR8HXM=@vger.kernel.org X-Gm-Message-State: AFuF++kswoySg8xK0actx9LVI+zOjwfmAywJiezQWcO3YoV7/AjiyMTh xKooxXaSli3DO9qTxbpHFOX7LaQ2ihFYXNwD/pDD6bI9WkImMqUlgsYc X-Gm-Gg: AYBFou3BLKlc/b0Q4A/+CzwRkE8k0IRiG4fZcOLoMbCPDETZzb7FSitMkbMWV95URJ/ cakMk4+gf9E3ysi+AZm8nE6ucMnSrUFFnygtBX1KLUnQPfBAkgA0xCSRNK70qh7nvakWbP/3Qw2 1W2wc66lKVCipYyzFmM1k5CISDoCyDQVsLH0XBXB25FIjJn3GEzHuTK+njPZ13iRPW2YXmq+/oA RCUqOhqCAvJm9+rg0by0icf998HQac6C4g6Hp9GZEnIL5QlB8i5ZCipdYCTLQaf4fVmn0/WfAYl L0VmHW0LRd25ZTk2nxXi8iyU/zF1cbFPGoCad825UbL1WNzXvxoPwSiPjJLGC9cW85w92v8/J/e 4CNkrgQtYEy0xQ4Oeen9FxkwdF0mKHL6QgRZk9Q1rGwIynWijamBYcTLZRJAy+AzYYJO58gWkj2 MqSne3yS6D5Sg1yMxs5RehTzNP43QogAo5nM2V1S8WTjnpq8ztw+qByIcCCSm/A3UKc7K2lFfXo NKi2vCdfExn9aNsDhg4pZOknZTcEMoOJwj1PfqlaA99/VZGYmzBs5e/tmAoH9SwgFFAl1DSmb7I 8Vs= X-Received: by 2002:a05:6a00:4655:b0:874:705d:f651 with SMTP id d2e1a72fcca58-874de60e6c9mr16128267b3a.31.1790018857181; Mon, 21 Sep 2026 12:27:37 -0700 (PDT) Received: from localhost ([153.61.198.252]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-87bf7eb8574sm1309b3a.43.2026.09.21.12.27.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 12:27:36 -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 19:27:36 +0000 Message-Id: To: "Eduard Zingerman" , "Vineet Gupta" 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" 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 7:10 PM UTC, Eduard Zingerman wrote: > On Mon, 2026-09-21 at 18:59 +0000, Alexei Starovoitov wrote: > > 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 = patches. > > > > > 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. > > >=20 > > > 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: > > >=20 > > > struct bpf_reg_state { > > > ... > > > s32 delta; > > > u32 id; > > > enum id_link_kind { full, zext, sext } link_kind; > > > ... > > > } > > >=20 > > > 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>= sext(rA % 32) =3D=3D sext(rB % 32) > >=20 > > hmm. > > there is also 32-bit link with delta, right? > > My point is that delta is independent of 32-bit/64-bit property. > `delta' can be used to propagate in both directions: > - full 64 bit -> 32 bit sign/zero-extened > - 32 bit sign/zero-extened -> full 64-bit both? how ? I was under impression that in 32-bit domain delta is one way. rX =3D ... wY =3D wX wY +=3D 5 if wY =3D=3D 10 We cannot do -5 to rX and we cannot use your above 'full' encoding for wY +=3D 5. Currently we use BPF_ADD_CONST32 for wY +=3D 5 I don't see how 'full' can work.