From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 5119A348C5C for ; Thu, 11 Jun 2026 06:48:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781160486; cv=none; b=ayo/wJZS3hy7RXR6AnNrNcd5Evdy7vklWnMCHZJqPx0c0T2QcfhK6d/yUws2GpuvNrnnWJPMd3NE3R8BI2YyNWQ0GkEKZKdaiorfu4SBaDjUiawqKcoYKNJht07aICW3/QuEJmbskJom5KO/wBNrZkYMTwfTG9XJqnsXDJ3koM8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781160486; c=relaxed/simple; bh=ta/gSKNvGoanoIlYiNOUoI1vgzNbOnFIlXHsHy7guYE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=F0RqLc9i4GDOjnpsv+gYZeY1zW/yMGw4f6DXOuCljLYb4SGSsctSr9TB5ZQrzH4OJohWv4S3OovBF4jJexbBVo/Rz+3zvuzXAf1uHPIj36h78vGt6fxEtDrQEDm4I/sGYw0qa/QLr6M7x+94NI15FAtfl9c4/XhJKIVQR4ck3Ug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=FLcDG9Cr; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="FLcDG9Cr" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-490ac357c55so79320045e9.1 for ; Wed, 10 Jun 2026 23:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1781160484; x=1781765284; 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=fAKTHXTGuL4/wSXAiskSC+BGLHaNjyNvdmJF1qOpYQQ=; b=FLcDG9CrgtP22lbv+GPacljZ4jk+JmpEwrIpiiQehpTGXE3RWGNmM3OHHdwdju9+JD mUP1Ek4PSOXazw7MOk66I4yOR1twi48Map7j6nXueFy2E90ZLkP0mSuUql8cu3iouP3k wkRpvX5igByT+ZIyE37wk2YTiODrS8UgnC8zZVhB+Cvmxj8lRKOVm6l9Yeaq1MmWGxcf xVXHdz7KJGpq6TmIgaJSWpx8RfHeLFXxydf8xbbc71HX0j5fB997/DZryt3o+mBy5O1I 5TqDOKpQiTwI+/RuHSNvHsbm5vCjz5z11LA1lmnB8mUN2PRDn17YcWAE9vWdfMU7P2lG og4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781160484; x=1781765284; 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=fAKTHXTGuL4/wSXAiskSC+BGLHaNjyNvdmJF1qOpYQQ=; b=b5hTFY+gco6uyW5Q7RKxx1SdoykQrz6jxDS8DptLiKpB0P56+q725gI6UdOzc1vI5J ddWSXi46ZkR/F0Kyr/9goOmuzoqdazmvb3rOGkGUMiWENEjjEKUyMwj6/7va2OxjScY1 u8bOk2BsrT2fDhCqeCWGBQhpwle2HbAVh2VaQQbQeghUn6Vr57O+vrRmNoU8LfmSzVMt 3mOrzpAvI+S6nCEh41NCa0AS/6ubv7aISH6FhOqcoeoeShfoPgAv6BQqhrgf9iZ4092K frIj1xjZXSk6mavvGIbQwpwQ4ILwIGXhRnJGFPXm9aA6+ANxYwOf47XxI/Dlcta0kQOz VCaw== X-Forwarded-Encrypted: i=1; AFNElJ975cDfJ3sxrJ/ucn2cq2hUruDJF9fky5YgcVZoOlE1fGITJdTDgGNxB2lzQUC+747/mKgTXOGCjZfKd+o=@vger.kernel.org X-Gm-Message-State: AOJu0YzkJF3DTb3XgbtcTDdCgP/tIIWUJwSmHtqTWzoizdow87EPihrA zOXfhp8gHcLiQo7h9gLQnR3TS2IqE4Voa0w3C3AS455a7LwUjD3zWzEXU8SkUz0f+Q8= X-Gm-Gg: Acq92OFzpFh0AHKB2xYf/kDKbBYTNgUWEzQLauUfXURxfNxJh9VH6lpqwBGGgp2MJXL Y29f0FiLp65+/eSwN97RftfhaLQJz3HrrkkavAxwI2QHp/qEg4ZS1L5PTD7hOJ2DfbJA7c5Kqbm VNW4lSXYoL5Y85rO47ZBVckT6q0+aFdEDEtltnbnfTRZKU6+DTtsTOj/ZgwMeFSkWAMd2RmviKC j32BOyWGs4h2laoOjIi4Dc7XmGA3vwu0w2CFeb2DiRhFgUSuz17YKEJD/c2NFfGTmIzOOWwaQDr MdUIyou4Kx//muuT9NfphcXbWyo3ASJZ4InJ8veWNGuRZ6pXSdn6yZN/rGg1EGfNxvIS5bVuQpg 8DJmVftJXnRb2v2//33MfqCtMLZffM1oJnLWN/W12dxxAbnGCaEESDfP7T5C5NIDlvAUSwtkgrl t2X/F20KfN0+suk7oin39bHsx5b4CdwadgX9w43NY7Ikhr/jEGtyktPH/HH/Ryp86N X-Received: by 2002:a05:600d:6447:20b0:490:c7dd:7cc2 with SMTP id 5b1f17b1804b1-490e561edccmr10410125e9.24.1781160482422; Wed, 10 Jun 2026 23:48:02 -0700 (PDT) Received: from u94a (27-51-16-188.adsl.fetnet.net. [27.51.16.188]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c164fa404fsm263800475ad.37.2026.06.10.23.47.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 23:48:01 -0700 (PDT) Date: Thu, 11 Jun 2026 14:47:48 +0800 From: Shung-Hsi Yu To: Zhenzhong Wu Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, menglong8.dong@gmail.com, eddyz87@gmail.com, stable@vger.kernel.org, mykolal@fb.com, tamird@kernel.org Subject: Re: [PATCH stable 6.6.y v2 0/3] bpf: backport scalar not-equal tracking fixes Message-ID: References: <20260607170959.823755-1-jt26wzz@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 Wed, Jun 10, 2026 at 11:46:18PM +0800, Zhenzhong Wu wrote: > > More importantly, 'bpf: make the verifier tracks the "not equal" for > > regs' does not address root cause of the issue, it merely mask the issue > > by making the two states different enough that the two is no longer > > equal, which works for the Rust specific case you have, but won't work > > if the value was slightly different (e.g. "r0 == 1" followed by "r0 != > > 1"). > > Thanks for spelling this out. I now see that I did not fully > understand the point behind your suggested bpf-next-with-d028-reverted > check. > > I was treating the not-equal refinement and the linked-scalar precision > issue as two ways to break the same failure chain, and chose the > d028-based path because it was smaller and easier for me to reason > about. With the `r0 == 1` variant, it became clear to me that this only > fixes the zero-valued branch shape from my original reproducer, while > the underlying linked-scalar pruning issue remains. > > > Could you give backporting the full "bpf: track find_equal_scalars history on > > per-instruction level" series[3] a try? For 6.6 it should be doable, and > > hopefully for 6.1, too, but not too sure about earlier ones. If you prefer I > > work on it I can also give it a try later this week. > > Sure, I will prepare v3 based on that series for 6.6.y, and then work > on the 6.1.y adaptation separately. > > I tried applying the series starting from 6.1.y and still hit some > issues that need adaptation. 5.15.y and 5.10.y appear to need more > surrounding verifier changes, so they may be harder, but I will still > try to work through them. If I run into anything I am unsure about, I > will raise it earlier. Thanks. Yeah besides the requirement of having to backport 6.6 before the same patch will be accepted in 6.1, personally I find it much eaiser to backport to newer stable to build understanding, before moving on to older ones; hopefully you'll should find starting with 6.6 first helps, too. > > As for the selftest, it would need to be send separately and by itself > > to bpf-next, and picked up there, before it can be backported to stable. > > I suggest you look at [4] and have your test placed similarly, and > > mention that your test specifically test a Rust/Aya pattern. > > Thanks, I will send the selftest to bpf-next separately. I will also > change the test to use the `r0 == 1` / `r0 != 1` shape, so it covers > the broader linked-scalar pruning issue instead of only the original > zero-valued case. Actually I thought it is better that you keep the `r0 == 0` / `r0 != 0` shape, the reason is that it seems to be the pattern produced by the compiler. But now that I think about it, using that shape in bpf-next means that impossible path will get min=1 due to the not-equal refinement, and thus precision won't matter. In that case using the `r0 == 1` / `r0 != 1` shape is probably better indeed. > Thanks again for the detailed explanation. I have only recently started > digging into the verifier implementation details, so this was very helpful! ... Happy to help! Shung-Hsi