[PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

[PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

[Michael Holzheu]

Looks like the "test_maps" test case expects to get the keys in
the wrong order when iterating over the elements:

test_maps: samples/bpf/test_maps.c:79: test_hashmap_sanity: Assertion
`bpf_get_next_key(map_fd, &key, &next_key) == 0 && next_key == 2' failed.
Aborted

Fix this and test for the correct order.  

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
 samples/bpf/test_maps.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/samples/bpf/test_maps.c
+++ b/samples/bpf/test_maps.c
@@ -69,9 +69,9 @@ static void test_hashmap_sanity(int i, v
 
 	/* iterate over two elements */
 	assert(bpf_get_next_key(map_fd, &key, &next_key) == 0 &&
-	       next_key == 2);
-	assert(bpf_get_next_key(map_fd, &next_key, &next_key) == 0 &&
 	       next_key == 1);
+	assert(bpf_get_next_key(map_fd, &next_key, &next_key) == 0 &&
+	       next_key == 2);
 	assert(bpf_get_next_key(map_fd, &next_key, &next_key) == -1 &&
 	       errno == ENOENT);
 

Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

[Alexei Starovoitov]

On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu
<holzheu@linux.vnet.ibm.com> wrote:
> Looks like the "test_maps" test case expects to get the keys in
> the wrong order when iterating over the elements:
>
> test_maps: samples/bpf/test_maps.c:79: test_hashmap_sanity: Assertion
> `bpf_get_next_key(map_fd, &key, &next_key) == 0 && next_key == 2' failed.
> Aborted
>
> Fix this and test for the correct order.

that will break this test on x86...
we need to understand first why the order of two elements
came out different on s390...
Could it be that jhash() produced different hash for the same
values on x86 vs s390 ?
The better fix for the test is probably not to assume AB or BA
order, but accept both.

Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test

[Michael Holzheu]

On Thu, 22 Jan 2015 09:32:43 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu
> <holzheu@linux.vnet.ibm.com> wrote:
> > Looks like the "test_maps" test case expects to get the keys in
> > the wrong order when iterating over the elements:
> >
> > test_maps: samples/bpf/test_maps.c:79: test_hashmap_sanity: Assertion
> > `bpf_get_next_key(map_fd, &key, &next_key) == 0 && next_key == 2' failed.
> > Aborted
> >
> > Fix this and test for the correct order.
> 
> that will break this test on x86...
> we need to understand first why the order of two elements
> came out different on s390...
> Could it be that jhash() produced different hash for the same
> values on x86 vs s390 ?

Yes I think jhash() produces different results for input > 12 bytes
on big and little endian machines because of the following code
in include/linux/jhash.h:

        while (length > 12) {
                a += __get_unaligned_cpu32(k);
                b += __get_unaligned_cpu32(k + 4);
                c += __get_unaligned_cpu32(k + 8);
                __jhash_mix(a, b, c);
                length -= 12;
                k += 12;
        }

The contents of "k" is directly used as u32 and the result
of "__get_unaligned_cpu32(k)" is different for big and
little endian.

Michael