> diff --git a/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> b/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> index 13777b3dcac8..816880c1cd5e 100644
> --- a/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> +++ b/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> @@ -618,7 +618,7 @@ int xdp_lb_bench(struct xdp_md *xdp)
> __u32 *saddr = data + saddr_off;
>
> batch_gen++;
> - batch_hash = (batch_gen + bpf_get_smp_processor_id()) *
> KNUTH_HASH_MULT;
> + batch_hash = ((batch_gen + bpf_get_smp_processor_id()) | 1) *
> KNUTH_HASH_MULT;
^^^^
Does forcing the LSB to 1 with '| 1' inadvertently destroy the lowest
bit of entropy from the batch generator?
Since batch_gen increments sequentially by 1 per batch execution,
forcing the least significant bit to 1 maps pairs of adjacent values
to the same number.
For example, if the CPU ID evaluates to 0, both batch_gen = 2 and
batch_gen = 3 will yield 3 before the multiplication:
batch_gen = 2, CPU = 0: (2 + 0) | 1 = 3
batch_gen = 3, CPU = 0: (3 + 0) | 1 = 3
Could this cause 50% of consecutive batches to generate the exact same
batch_hash as the previous batch, causing those iterations to hit the
warm LRU cache entries that were just populated and defeating the
purpose of the cold_lru benchmark?
This concern was raised in Puranjay's v1 patch where he used XOR instead
of addition, and he acknowledged the issue and switched to plain addition
in v2. This patch reintroduces the same '| 1' approach with addition, but
the entropy-loss problem remains.
Referenced discussion:
https://lore.kernel.org/bpf/2afdea40f0c5a11c2337efafe6f460899d85bc28650e04d5e0b9ceb35f3ad...@mail.kernel.org/
> if ((void *)(saddr + 1) <= data_end)
> *saddr ^= batch_hash;
> }
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26188863722
