From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (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 0347533263E for ; Tue, 2 Jun 2026 09:18:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780391898; cv=none; b=L/iETqZO/aQHZ/wHYXr2z+cjrQh/t2NokUBh9Bl0L8r5M9V1fcUx1qChTeGOmlJsW5AR3d2zKVl5NQBaY5TzIO/JE0geniG/m5n2SHA28/k1gbX+Gvr4SSkUynIv6Vvlb02NSYpKZxXWI7PYrIfpSGgRVq2FzyASLANHvHPvmlU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780391898; c=relaxed/simple; bh=FYGX+z1NHS6G0DY02oZQ6hTTBFd4DJcBw8FAvVlqv/Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Aj1d0shyJXvghQ3eBbVEhV0INJ3Bh8yl3+ffikYmQ96uOJcKJtIaX8BSe2x3U3coMl8Qkwv1Mq5jQrEz/wtDXf1g/Xl7o+oScmYviNRgyJC6bPHJSefd/7eL9r/tXe75CZ2xu/oKJW8xr+S76lXtT7F/15GeRtGFEeMxJLLfK28= 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=LWb2KaeB; arc=none smtp.client-ip=209.85.218.51 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="LWb2KaeB" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-bebbc325000so302547266b.0 for ; Tue, 02 Jun 2026 02:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1780391895; x=1780996695; 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=8weWZwvlicUS0dvAxblKD1HBMYQh1u5mQ2U5bxBouSc=; b=LWb2KaeBuGlQuxF2ygVImG8z4k6CWEfaz8CIF20uqpcIp1Z/93bnC+RGYjgbcyS3DT Bpzm6hJMKdWRjIsE50U5MFlQBwL+kknijzd2EJC0arOwnoenhvloVr3CD/Dsa4VcYEBu GY4VF1Bl1OppX4jipLsrAg4r1QppX6Ry0lBgZRF9dOA2/gbepWfZgfURLWNmuXVwUoYs YaxlUZ+Zfgii3NCsewGG4TRrGe4euGOzb60mmQxXKpVtMk1Wd1CI9dvIna+pKHYCXuUa ijTY/DAk5DAWuF+1uq4KEPQdf3TqZfaUWGocJWqxyi24zbd/ufyOHgYbm2r5OBJkOpYu /vgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780391895; x=1780996695; 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=8weWZwvlicUS0dvAxblKD1HBMYQh1u5mQ2U5bxBouSc=; b=VCruUhNgOEC9CqBXmfU4723AMKSE5feuHXxIsLYD2h7CQx39+kvsF9wByJOikD1PiD w1KiDR8t0B6GTolgjRzHXrVzODJz/9QOS/ZkuXY+fUxVDwtyk0fxhpHRSDRgYRccqHOC HZpH7lI0VzVIBszw310A16cxuod7jQj4Yt7XpmNkVSBIyzqu/KVViVZ+IW6nvnFFQ4Vv Fc/kx0FaZEXE8uEx+SdA9jOSNcyvgRjTFof02+K4c6pvuW13nYot7BeiHRxxIaEsF9pT am1He+LMI08Eb4EGeRrlMW180FRn9fSpH3xldZEeX9JLYiTbtjEChu5BeD7sWm0goR0e 5YBw== X-Forwarded-Encrypted: i=1; AFNElJ/IQ2RydQQpTnbyLwEfoKlPT3IkFFT4k8/io9gVHvPwX75LVWLFPiZBkbjH7aQyj54cJBpjTFdPJP6BiNI=@vger.kernel.org X-Gm-Message-State: AOJu0YzmLfca4HT1xYUUWloEM0+zG9/BxZZp637qKWqXPDZu54vhO5z0 AcaevNuCBfNsgjZmMini+mxKb5HiMwaH81hYn/7BaPXxbM5NnxIGjvjnPWIW8nhuQW8= X-Gm-Gg: Acq92OGWqHPza7pAL7079T8S4sWFLUXIQXkNlHEWrHz/tkzT+/QMg8c8bEK6TZJliRK F/p6wWXlzV417AJ3FyXBb2ILuAppqFyOuMOBu+Fp5hLur1vZWrk8y6Q1T7soIE+RKRvKsNK9GYT L5rQYeO34ToT+cOHPGEC+Nx+rQslxkcQ3MdclJG0jFeRAx2TuLIzn972DVOmT1+lVJu9Eo5/y3r VEZM207msa1QllKTyExJBktetmf827E8oHgSc7G2cpzuTUD9jswnGW7wnA3g+InsvGrkIp1Zhq3 X0TmGIqNIGu5tDhXIqIeiCwWx1UiAe+SC9XxhYOMvwJ9ELUKVXZs+xi7ufvZ0FZVzmAXyZvzJ74 UmAq4umR2VSMfPkq/HYeIN3Il/ECHzl2OW+wEL4oAk1u+C1Zglx+T8jbFONRo2oMKACn58lud3A 2AlpMnZxJ4sjt9po+fqYLu/AFLGcEKIAiV+hdO+ZdLW0/N4LicV99diA== X-Received: by 2002:a17:907:9453:b0:bea:5cc7:95a4 with SMTP id a640c23a62f3a-beab03de8a1mr933593866b.0.1780391895233; Tue, 02 Jun 2026 02:18:15 -0700 (PDT) Received: from u94a (27-240-75-84.adsl.fetnet.net. [27.240.75.84]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36dd91846f8sm2382956a91.4.2026.06.02.02.18.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 02:18:14 -0700 (PDT) Date: Tue, 2 Jun 2026 17:17:59 +0800 From: Shung-Hsi Yu To: Zhenzhong Wu Cc: stable@vger.kernel.org, Paul Chaignon , 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, haoluo@google.com, jolsa@kernel.org, menglong8.dong@gmail.com, tamird@kernel.org, eddyz87@gmail.com Subject: Re: [RFC PATCH 6.1.y 0/2] bpf: backport scalar not-equal tracking fixes Message-ID: References: <20260601180400.1381736-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 Tue, Jun 02, 2026 at 02:42:35PM +0800, Shung-Hsi Yu wrote: > On Tue, Jun 02, 2026 at 01:47:01PM +0800, Shung-Hsi Yu wrote: > ... > > On Tue, Jun 02, 2026 at 02:03:58AM +0800, Zhenzhong Wu wrote: > > > Hi BPF maintainers, > > > > > > This RFC backports two BPF verifier scalar range-tracking fixes to 6.1.y. > > > The series is intended to fix a verifier state-pruning issue where an > > > impossible scalar path can be kept while the real success path is pruned. > > > > > > This is a verifier scalar range-tracking issue, not a helper-specific > > > issue. > > > The visible failure is that the verifier can prune the real success > > > continuation, which should not be skipped, and keep only an impossible one. > > ... > > > > This sounds somewhat similar to the issue fixed in "backport of iterator > > and callback handling fixes" for stable 6.6[1] by @Eduard. Could you try > > to test on the latest stable 6.6.y as well at see if you can reproduce > > the issue there? > ... > > My mistake, the reproducer you had doesn't use iterator or callback, so > probably not fixed in stable 6.6. I'll take a better look at this later > this week. Two more ideas beside testing on latest stable 6.6. 1. Can you try testing on bpf-next, but with commit d028f87517d6 'bpf: make the verifier tracks the "not equal" for regs' reverted? My concern is that it is possible that commit d028f87517d6 does not address the root cause of incorrect state pruning here. If the reproducer _fails_ to reproduce the issue even with commit d028f87517d6 reverted, then it is possible that the root cause was fixed by another commit further down the line. 2. Have you consider adding your reproducer into BPF selftests? Would be very useful to have in stable (though it needs to first land in bpf-next first). > > 1: https://lore.kernel.org/stable/20240125001554.25287-1-eddyz87@gmail.com/ > > 2: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html