In BPF_AND and BPF_OR alu cases we have this pattern when the src and dst tnum is a constant. 1 dst_reg->var_off = tnum_[op](dst_reg->var_off, src_reg.var_off) 2 scalar32_min_max_[op] 3 if (known) return 4 scalar_min_max_[op] 5 if (known) 6 __mark_reg_known(dst_reg, dst_reg->var_off.value [op] src_reg.var_off.value) The result is in 1 we calculate the var_off value and store it in the dst_reg. Then in 6 we duplicate this logic doing the op again on the value. The duplication comes from the the tnum_[op] handlers because they have already done the value calcuation. For example this is tnum_and(). struct tnum tnum_and(struct tnum a, struct tnum b) { u64 alpha, beta, v; alpha = a.value | a.mask; beta = b.value | b.mask; v = a.value & b.value; return TNUM(v, alpha & beta & ~v); } So lets remove the redundant op calculation. Its confusing for readers and unnecessary. Its also not harmful because those ops have the property, r1 & r1 = r1 and r1 | r1 = r1.
Unified · Split
| @@ -5849,8 +5849,7 @@ static void scalar_min_max_and(struct bpf_reg_state *dst_reg, · 5848 unmodified lines | ||
| 5849 | 5849 | u64 umax_val = src_reg->umax_value; |
| 5850 | 5850 | |
| 5851 | 5851 | if (src_known && dst_known) { |
| 5852 | − __mark_reg_known(dst_reg, dst_reg->var_off.value & | |
| 5853 | − src_reg->var_off.value); | |
| 5852 | + __mark_reg_known(dst_reg, dst_reg->var_off.value); | |
| 5854 | 5853 | return; |
| 5855 | 5854 | } |
| 5856 | 5855 | |
| @@ -5920,8 +5919,7 @@ static void scalar_min_max_or(struct bpf_reg_state *dst_reg, · 63 unmodified lines | ||
| 5920 | 5919 | u64 umin_val = src_reg->umin_value; |
| 5921 | 5920 | |
| 5922 | 5921 | if (src_known && dst_known) { |
| 5923 | − __mark_reg_known(dst_reg, dst_reg->var_off.value | | |
| 5924 | − src_reg->var_off.value); | |
| 5922 | + __mark_reg_known(dst_reg, dst_reg->var_off.value); | |
| 5925 | 5923 | return; |
| 5926 | 5924 | } |
| 5927 | 5925 | |