Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
On Thu, 22 Jan 2015 09:32:43 -0800
Alexei Starovoitov wrote:
> On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu
> 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) == 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
On Thu, 22 Jan 2015 09:32:43 -0800
Alexei Starovoitov alexei.starovoi...@gmail.com wrote:
On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu
holz...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu 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) == 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
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) == 0 && next_key == 2' failed. Aborted Fix this and test for the correct order. Signed-off-by: Michael Holzheu --- 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) == 0 && - next_key == 2); - assert(bpf_get_next_key(map_fd, _key, _key) == 0 && next_key == 1); + assert(bpf_get_next_key(map_fd, _key, _key) == 0 && + next_key == 2); assert(bpf_get_next_key(map_fd, _key, _key) == -1 && errno == ENOENT); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
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 holz...@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); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] samples/bpf: Fix test_maps/bpf_get_next_key() test
On Thu, Jan 22, 2015 at 8:01 AM, Michael Holzheu holz...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
