diff mbox series

test/bpf: fix auto-test with clang fails

Message ID 20211018134052.10514-1-konstantin.ananyev@intel.com (mailing list archive)
State Accepted, archived
Delegated to: David Marchand
Headers show
Series test/bpf: fix auto-test with clang fails | expand

Checks

Context Check Description
ci/intel-Testing success Testing PASS
ci/Intel-compilation success Compilation OK
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-aarch64-compile-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-x86_64-compile-testing success Testing PASS
ci/iol-x86_64-unit-testing success Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/github-robot: build success github build: passed
ci/checkpatch success coding style OK

Commit Message

Ananyev, Konstantin Oct. 18, 2021, 1:40 p.m. UTC
test_shift1_check() function fails with clang build.
The reason for that is that clang uses 64-bit shift instruction for
what expected to be 32-bit operation.
To be more specific, this C code:
r2 = (uint32_t)r2 >> r4;
With clang produces:
41a4eb:       48 d3 ef                shr    %cl,%rdi
In that particular case it is an allowed choice, as from one side
left-operand value is known to fit into 32 bits, from other side
according to 'C' standard:
"...if the value of the right operand is negative or is greater than
or equal to the width of the promoted left operand, the behavior is
undefined."
The problem is that on x86 behavior for 64-bit and 32-bit shift
operation might differ.
The fix avoids undefined behavior by making sure
that right operand will not exceed width of the promoted left operand.

Bugzilla ID: 811
Fixes: 9f8f9d91a701 ("test/bpf: introduce functional test")
Cc: stable@dpdk.org

Reported-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
 app/test/test_bpf.c | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

Comments

Stephen Hemminger Oct. 18, 2021, 3:58 p.m. UTC | #1
On Mon, 18 Oct 2021 14:40:52 +0100
Konstantin Ananyev <konstantin.ananyev@intel.com> wrote:

> test_shift1_check() function fails with clang build.
> The reason for that is that clang uses 64-bit shift instruction for
> what expected to be 32-bit operation.
> To be more specific, this C code:
> r2 = (uint32_t)r2 >> r4;
> With clang produces:
> 41a4eb:       48 d3 ef                shr    %cl,%rdi
> In that particular case it is an allowed choice, as from one side
> left-operand value is known to fit into 32 bits, from other side
> according to 'C' standard:
> "...if the value of the right operand is negative or is greater than
> or equal to the width of the promoted left operand, the behavior is
> undefined."
> The problem is that on x86 behavior for 64-bit and 32-bit shift
> operation might differ.
> The fix avoids undefined behavior by making sure
> that right operand will not exceed width of the promoted left operand.
> 
> Bugzilla ID: 811
> Fixes: 9f8f9d91a701 ("test/bpf: introduce functional test")
> Cc: stable@dpdk.org
> 
> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>

Thanks

Acked-by: Stephen Hemminger <stephen@networkplumber.org>
David Marchand Oct. 20, 2021, 6:46 p.m. UTC | #2
On Mon, Oct 18, 2021 at 5:59 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Konstantin Ananyev <konstantin.ananyev@intel.com> wrote:
> > test_shift1_check() function fails with clang build.
> > The reason for that is that clang uses 64-bit shift instruction for
> > what expected to be 32-bit operation.
> > To be more specific, this C code:
> > r2 = (uint32_t)r2 >> r4;
> > With clang produces:
> > 41a4eb:       48 d3 ef                shr    %cl,%rdi
> > In that particular case it is an allowed choice, as from one side
> > left-operand value is known to fit into 32 bits, from other side
> > according to 'C' standard:
> > "...if the value of the right operand is negative or is greater than
> > or equal to the width of the promoted left operand, the behavior is
> > undefined."
> > The problem is that on x86 behavior for 64-bit and 32-bit shift
> > operation might differ.
> > The fix avoids undefined behavior by making sure
> > that right operand will not exceed width of the promoted left operand.
> >
> > Bugzilla ID: 811
> > Fixes: 9f8f9d91a701 ("test/bpf: introduce functional test")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>

Applied, thanks.

Probably worth adding bpf_autotest in the fast-tests list.
There are other missing tests in this list, for my todolist unless
someone wants to look at it.
Stephen Hemminger Oct. 20, 2021, 8:51 p.m. UTC | #3
On Wed, 20 Oct 2021 20:46:31 +0200
David Marchand <david.marchand@redhat.com> wrote:

> On Mon, Oct 18, 2021 at 5:59 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > Konstantin Ananyev <konstantin.ananyev@intel.com> wrote:  
> > > test_shift1_check() function fails with clang build.
> > > The reason for that is that clang uses 64-bit shift instruction for
> > > what expected to be 32-bit operation.
> > > To be more specific, this C code:
> > > r2 = (uint32_t)r2 >> r4;
> > > With clang produces:
> > > 41a4eb:       48 d3 ef                shr    %cl,%rdi
> > > In that particular case it is an allowed choice, as from one side
> > > left-operand value is known to fit into 32 bits, from other side
> > > according to 'C' standard:
> > > "...if the value of the right operand is negative or is greater than
> > > or equal to the width of the promoted left operand, the behavior is
> > > undefined."
> > > The problem is that on x86 behavior for 64-bit and 32-bit shift
> > > operation might differ.
> > > The fix avoids undefined behavior by making sure
> > > that right operand will not exceed width of the promoted left operand.
> > >
> > > Bugzilla ID: 811
> > > Fixes: 9f8f9d91a701 ("test/bpf: introduce functional test")
> > > Cc: stable@dpdk.org
> > >
> > > Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> > > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>  
> > Acked-by: Stephen Hemminger <stephen@networkplumber.org>  
> 
> Applied, thanks.
> 
> Probably worth adding bpf_autotest in the fast-tests list.
> There are other missing tests in this list, for my todolist unless
> someone wants to look at it.

That is what found this...
https://patchwork.dpdk.org/project/dpdk/patch/20211015201129.63220-11-stephen@networkplumber.org/
diff mbox series

Patch

diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
index 8118a1849b..7fcf92e716 100644
--- a/app/test/test_bpf.c
+++ b/app/test/test_bpf.c
@@ -59,6 +59,9 @@  struct dummy_mbuf {
 #define TEST_SHIFT_1	15
 #define TEST_SHIFT_2	33
 
+#define TEST_SHIFT32_MASK	(CHAR_BIT * sizeof(uint32_t) - 1)
+#define TEST_SHIFT64_MASK	(CHAR_BIT * sizeof(uint64_t) - 1)
+
 #define TEST_JCC_1	0
 #define TEST_JCC_2	-123
 #define TEST_JCC_3	5678
@@ -548,15 +551,25 @@  static const struct ebpf_insn test_shift1_prog[] = {
 		.off = offsetof(struct dummy_vect8, out[1].u64),
 	},
 	{
-		.code = (BPF_ALU | BPF_RSH | BPF_X),
-		.dst_reg = EBPF_REG_2,
-		.src_reg = EBPF_REG_4,
+		.code = (BPF_ALU | BPF_AND | BPF_K),
+		.dst_reg = EBPF_REG_4,
+		.imm = TEST_SHIFT64_MASK,
 	},
 	{
 		.code = (EBPF_ALU64 | BPF_LSH | BPF_X),
 		.dst_reg = EBPF_REG_3,
 		.src_reg = EBPF_REG_4,
 	},
+	{
+		.code = (BPF_ALU | BPF_AND | BPF_K),
+		.dst_reg = EBPF_REG_4,
+		.imm = TEST_SHIFT32_MASK,
+	},
+	{
+		.code = (BPF_ALU | BPF_RSH | BPF_X),
+		.dst_reg = EBPF_REG_2,
+		.src_reg = EBPF_REG_4,
+	},
 	{
 		.code = (BPF_STX | BPF_MEM | EBPF_DW),
 		.dst_reg = EBPF_REG_1,
@@ -590,7 +603,7 @@  static const struct ebpf_insn test_shift1_prog[] = {
 	{
 		.code = (BPF_ALU | BPF_AND | BPF_K),
 		.dst_reg = EBPF_REG_2,
-		.imm = sizeof(uint64_t) * CHAR_BIT - 1,
+		.imm = TEST_SHIFT64_MASK,
 	},
 	{
 		.code = (EBPF_ALU64 | EBPF_ARSH | BPF_X),
@@ -600,7 +613,7 @@  static const struct ebpf_insn test_shift1_prog[] = {
 	{
 		.code = (BPF_ALU | BPF_AND | BPF_K),
 		.dst_reg = EBPF_REG_2,
-		.imm = sizeof(uint32_t) * CHAR_BIT - 1,
+		.imm = TEST_SHIFT32_MASK,
 	},
 	{
 		.code = (BPF_ALU | BPF_LSH | BPF_X),
@@ -666,8 +679,10 @@  test_shift1_check(uint64_t rc, const void *arg)
 	dve.out[0].u64 = r2;
 	dve.out[1].u64 = r3;
 
-	r2 = (uint32_t)r2 >> r4;
+	r4 &= TEST_SHIFT64_MASK;
 	r3 <<= r4;
+	r4 &= TEST_SHIFT32_MASK;
+	r2 = (uint32_t)r2 >> r4;
 
 	dve.out[2].u64 = r2;
 	dve.out[3].u64 = r3;
@@ -676,9 +691,9 @@  test_shift1_check(uint64_t rc, const void *arg)
 	r3 = dvt->in[1].u64;
 	r4 = dvt->in[2].u32;
 
-	r2 &= sizeof(uint64_t) * CHAR_BIT - 1;
+	r2 &= TEST_SHIFT64_MASK;
 	r3 = (int64_t)r3 >> r2;
-	r2 &= sizeof(uint32_t) * CHAR_BIT - 1;
+	r2 &= TEST_SHIFT32_MASK;
 	r4 = (uint32_t)r4 << r2;
 
 	dve.out[4].u64 = r4;