From: kernel test robot <lkp@intel.com>
To: Yazhou Tang <tangyazhou@zju.edu.cn>, bpf@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, ast@kernel.org,
daniel@iogearbox.net, john.fastabend@gmail.com,
andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com,
song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org,
sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org,
tangyazhou518@outlook.com, shenghaoyuan0928@163.com,
ziye@zju.edu.cn, syzbot@syzkaller.appspotmail.com
Subject: Re: [PATCH bpf-next v3 1/2] bpf: Add range tracking for BPF_DIV and BPF_MOD
Date: Wed, 14 Jan 2026 08:48:06 +0800 [thread overview]
Message-ID: <202601140812.rsul8sPI-lkp@intel.com> (raw)
In-Reply-To: <20260113103552.3435695-2-tangyazhou@zju.edu.cn>
Hi Yazhou,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Yazhou-Tang/bpf-Add-range-tracking-for-BPF_DIV-and-BPF_MOD/20260113-184035
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link: https://lore.kernel.org/r/20260113103552.3435695-2-tangyazhou%40zju.edu.cn
patch subject: [PATCH bpf-next v3 1/2] bpf: Add range tracking for BPF_DIV and BPF_MOD
config: riscv-randconfig-002-20260114 (https://download.01.org/0day-ci/archive/20260114/202601140812.rsul8sPI-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 9.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260114/202601140812.rsul8sPI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601140812.rsul8sPI-lkp@intel.com/
All errors (new ones prefixed by >>):
kernel/bpf/verifier.c: In function 'adjust_scalar_min_max_vals':
>> kernel/bpf/verifier.c:15865:3: error: a label can only be part of a statement and a declaration is not a statement
15865 | bool changed = true;
| ^~~~
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for CAN_DEV
Depends on [n]: NETDEVICES [=n] && CAN [=y]
Selected by [y]:
- CAN [=y] && NET [=y]
vim +15865 kernel/bpf/verifier.c
15781
15782 /* WARNING: This function does calculations on 64-bit values, but the actual
15783 * execution may occur on 32-bit values. Therefore, things like bitshifts
15784 * need extra checks in the 32-bit case.
15785 */
15786 static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
15787 struct bpf_insn *insn,
15788 struct bpf_reg_state *dst_reg,
15789 struct bpf_reg_state src_reg)
15790 {
15791 u8 opcode = BPF_OP(insn->code);
15792 s16 off = insn->off;
15793 bool alu32 = (BPF_CLASS(insn->code) != BPF_ALU64);
15794 int ret;
15795
15796 if (!is_safe_to_compute_dst_reg_range(insn, &src_reg)) {
15797 __mark_reg_unknown(env, dst_reg);
15798 return 0;
15799 }
15800
15801 if (sanitize_needed(opcode)) {
15802 ret = sanitize_val_alu(env, insn);
15803 if (ret < 0)
15804 return sanitize_err(env, insn, ret, NULL, NULL);
15805 }
15806
15807 /* Calculate sign/unsigned bounds and tnum for alu32 and alu64 bit ops.
15808 * There are two classes of instructions: The first class we track both
15809 * alu32 and alu64 sign/unsigned bounds independently this provides the
15810 * greatest amount of precision when alu operations are mixed with jmp32
15811 * operations. These operations are BPF_ADD, BPF_SUB, BPF_MUL, BPF_ADD,
15812 * and BPF_OR. This is possible because these ops have fairly easy to
15813 * understand and calculate behavior in both 32-bit and 64-bit alu ops.
15814 * See alu32 verifier tests for examples. The second class of
15815 * operations, BPF_LSH, BPF_RSH, and BPF_ARSH, however are not so easy
15816 * with regards to tracking sign/unsigned bounds because the bits may
15817 * cross subreg boundaries in the alu64 case. When this happens we mark
15818 * the reg unbounded in the subreg bound space and use the resulting
15819 * tnum to calculate an approximation of the sign/unsigned bounds.
15820 */
15821 switch (opcode) {
15822 case BPF_ADD:
15823 scalar32_min_max_add(dst_reg, &src_reg);
15824 scalar_min_max_add(dst_reg, &src_reg);
15825 dst_reg->var_off = tnum_add(dst_reg->var_off, src_reg.var_off);
15826 break;
15827 case BPF_SUB:
15828 scalar32_min_max_sub(dst_reg, &src_reg);
15829 scalar_min_max_sub(dst_reg, &src_reg);
15830 dst_reg->var_off = tnum_sub(dst_reg->var_off, src_reg.var_off);
15831 break;
15832 case BPF_NEG:
15833 env->fake_reg[0] = *dst_reg;
15834 __mark_reg_known(dst_reg, 0);
15835 scalar32_min_max_sub(dst_reg, &env->fake_reg[0]);
15836 scalar_min_max_sub(dst_reg, &env->fake_reg[0]);
15837 dst_reg->var_off = tnum_neg(env->fake_reg[0].var_off);
15838 break;
15839 case BPF_MUL:
15840 dst_reg->var_off = tnum_mul(dst_reg->var_off, src_reg.var_off);
15841 scalar32_min_max_mul(dst_reg, &src_reg);
15842 scalar_min_max_mul(dst_reg, &src_reg);
15843 break;
15844 case BPF_DIV:
15845 if (alu32) {
15846 if (off == 1)
15847 scalar32_min_max_sdiv(dst_reg, &src_reg);
15848 else
15849 scalar32_min_max_udiv(dst_reg, &src_reg);
15850 __mark_reg64_unbounded(dst_reg);
15851 } else {
15852 if (off == 1)
15853 scalar_min_max_sdiv(dst_reg, &src_reg);
15854 else
15855 scalar_min_max_udiv(dst_reg, &src_reg);
15856 __mark_reg32_unbounded(dst_reg);
15857 }
15858 /* Since we don't have precise tnum analysis for division yet,
15859 * we must reset var_off to unknown to avoid inconsistency.
15860 * Subsequent reg_bounds_sync() will rebuild it from scalar bounds.
15861 */
15862 dst_reg->var_off = tnum_unknown;
15863 break;
15864 case BPF_MOD:
15865 bool changed = true;
15866 if (alu32)
15867 changed = (off == 1) ? scalar32_min_max_smod(dst_reg, &src_reg)
15868 : scalar32_min_max_umod(dst_reg, &src_reg);
15869 else
15870 changed = (off == 1) ? scalar_min_max_smod(dst_reg, &src_reg)
15871 : scalar_min_max_umod(dst_reg, &src_reg);
15872 /* Similar to BPF_DIV, we need to reset var_off and 32/64 range
15873 * to unknown (unbounded). But if the result is equal to dividend
15874 * (due to special cases in BPF_MOD analysis), we can also keep
15875 * them unchanged.
15876 */
15877 if (changed) {
15878 if (alu32)
15879 __mark_reg64_unbounded(dst_reg);
15880 else
15881 __mark_reg32_unbounded(dst_reg);
15882 dst_reg->var_off = tnum_unknown;
15883 }
15884 break;
15885 case BPF_AND:
15886 dst_reg->var_off = tnum_and(dst_reg->var_off, src_reg.var_off);
15887 scalar32_min_max_and(dst_reg, &src_reg);
15888 scalar_min_max_and(dst_reg, &src_reg);
15889 break;
15890 case BPF_OR:
15891 dst_reg->var_off = tnum_or(dst_reg->var_off, src_reg.var_off);
15892 scalar32_min_max_or(dst_reg, &src_reg);
15893 scalar_min_max_or(dst_reg, &src_reg);
15894 break;
15895 case BPF_XOR:
15896 dst_reg->var_off = tnum_xor(dst_reg->var_off, src_reg.var_off);
15897 scalar32_min_max_xor(dst_reg, &src_reg);
15898 scalar_min_max_xor(dst_reg, &src_reg);
15899 break;
15900 case BPF_LSH:
15901 if (alu32)
15902 scalar32_min_max_lsh(dst_reg, &src_reg);
15903 else
15904 scalar_min_max_lsh(dst_reg, &src_reg);
15905 break;
15906 case BPF_RSH:
15907 if (alu32)
15908 scalar32_min_max_rsh(dst_reg, &src_reg);
15909 else
15910 scalar_min_max_rsh(dst_reg, &src_reg);
15911 break;
15912 case BPF_ARSH:
15913 if (alu32)
15914 scalar32_min_max_arsh(dst_reg, &src_reg);
15915 else
15916 scalar_min_max_arsh(dst_reg, &src_reg);
15917 break;
15918 default:
15919 break;
15920 }
15921
15922 /* ALU32 ops are zero extended into 64bit register */
15923 if (alu32)
15924 zext_32_to_64(dst_reg);
15925 reg_bounds_sync(dst_reg);
15926 return 0;
15927 }
15928
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2026-01-14 0:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 10:35 [PATCH bpf-next v3 0/2] bpf: Add range tracking for BPF_DIV and BPF_MOD Yazhou Tang
2026-01-13 10:35 ` [PATCH bpf-next v3 1/2] " Yazhou Tang
2026-01-14 0:48 ` kernel test robot [this message]
2026-01-14 3:08 ` Alexei Starovoitov
2026-01-14 5:47 ` Yazhou Tang
2026-01-15 3:53 ` Alexei Starovoitov
2026-01-15 5:05 ` Yazhou Tang
2026-01-13 10:35 ` [PATCH bpf-next v3 2/2] selftests/bpf: Add tests for BPF_DIV and BPF_MOD range tracking Yazhou Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202601140812.rsul8sPI-lkp@intel.com \
--to=lkp@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=sdf@fomichev.me \
--cc=shenghaoyuan0928@163.com \
--cc=song@kernel.org \
--cc=syzbot@syzkaller.appspotmail.com \
--cc=tangyazhou518@outlook.com \
--cc=tangyazhou@zju.edu.cn \
--cc=yonghong.song@linux.dev \
--cc=ziye@zju.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.