Re: [PATCH 06/14] bpf/tests: Add more BPF_LSH/RSH/ARSH tests for ALU64

[Yonghong Song <yhs@fb.com>]

On 7/28/21 10:04 AM, Johan Almbladh wrote:
> This patch adds a number of tests for BPF_LSH, BPF_RSH amd BPF_ARSH
> ALU64 operations with values that may trigger different JIT code paths.
> Mainly testing 32-bit JITs that implement ALU64 operations with two
> 32-bit CPU registers per operand.
> 
> Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
> ---
>   lib/test_bpf.c | 544 ++++++++++++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 542 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> index ef75dbf53ec2..b930fa35b9ef 100644
> --- a/lib/test_bpf.c
> +++ b/lib/test_bpf.c
> @@ -4139,6 +4139,106 @@ static struct bpf_test tests[] = {
>   		{ },
>   		{ { 0, 0x80000000 } },
>   	},
> +	{
> +		"ALU64_LSH_X: Shift < 32, low word",
> +		.u.insns_int = {
> +			BPF_LD_IMM64(R0, 0x0123456789abcdefLL),
> +			BPF_ALU32_IMM(BPF_MOV, R1, 12),
> +			BPF_ALU64_REG(BPF_LSH, R0, R1),
> +			BPF_EXIT_INSN(),
> +		},
> +		INTERNAL,
> +		{ },
> +		{ { 0, 0xbcdef000 } }

In bpf_test struct, the result is defined as __u32
         struct {
                 int data_size;
                 __u32 result;
         } test[MAX_SUBTESTS];

But the above result 0xbcdef000 does not really capture the bpf program
return value, which should be 0x3456789abcdef000.
Can we change "result" type to __u64 so the result truly captures the 
program return value?

We have several other similar cases for the rest of this patch.

> +	},
> +	{
> +		"ALU64_LSH_X: Shift < 32, high word",
> +		.u.insns_int = {
> +			BPF_LD_IMM64(R0, 0x0123456789abcdefLL),
> +			BPF_ALU32_IMM(BPF_MOV, R1, 12),
> +			BPF_ALU64_REG(BPF_LSH, R0, R1),
> +			BPF_ALU64_IMM(BPF_RSH, R0, 32),
> +			BPF_EXIT_INSN(),
> +		},
> +		INTERNAL,
> +		{ },
> +		{ { 0, 0x3456789a } }
> +	},
[...]