Hi Alex,
On 05/07/2019 14:45, Alex Kiselev wrote:
Hi,
<snip>
As a general remark consider writing all of the tbl entries including
tbl8 with atomic_store. Now "lpm->tbl8[j] = new_tbl8_entry;" is looks like
1e9: 44 88 9c 47 40 01 00 mov
%r11b,0x2000140(%rdi,%rax,2) <-write first byte
1f0: 02
1f1: 48 83 c0 01 add $0x1,%rax
1f5: 42 88 8c 47 41 01 00 mov %cl,0x2000141(%rdi,%r8,2) <-write
second byte
1fc: 02
This may cause an incorrect nexthop to be returned. If the byte with valid flag
is updated first, the old(and maybe invalid) next hop could be returned.
+1
It is surprising that the compiler is not generating a single 32b store. As you
mentioned 'relaxed' __atomic_store_n should be good.
Am I right that x86 platform is not affected by the bug since
store-store could not be reordered on x86?
You right, x86 shouldn't be affected. If I understand asm correctly
nexthop is written first for both _v20 and _v1604. Memory stores are
retired in order.
--
Regards,
Vladimir
