All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-08-26  5:26 suy.fnst
  2021-08-26  9:36 ` Alexey Kodanev
  0 siblings, 1 reply; 12+ messages in thread
From: suy.fnst @ 2021-08-26  5:26 UTC (permalink / raw)
  To: ltp

While running mpls02.sh -6 in our slow test box with kernel
version > v5.11, we found the test hangs at ping6 occasionally:

  + grep -q 'invalid option'
  + for size in ${msg_sizes:-"56"}
  + EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1
  '>/dev/null'
  + _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f
  fd00:23::1 '>/dev/null'
  + local fnc=tst_res
  + shift
  + tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null'

The weird part is that manual ping6 works in the meantime.

Then we found that adding `sleep 1` at end of mpls02.sh/setup() make
the test pass in 100%. Dig depper in the problem, ftrace catched during
the 1 second shows (The test started at [ 3979.485488]):

 3981.210701 |   2) kworker-24742  |               |  addrconf_dad_work() {
 3981.210712 |   2) kworker-24742  |               |    addrconf_dad_completed() {
 3981.210712 |   2) kworker-24742  |   0.417 us    |      addrconf_del_dad_work();
 3981.210713 |   2) kworker-24742  |               |      __ipv6_ifa_notify() {
 3981.210716 |   2) kworker-24742  |   1.097 us    |        inet6_fill_ifaddr();
 3981.210730 |   2) kworker-24742  |               |        ip6_ins_rt() {
 3981.210731 |   2) kworker-24742  |               |          fib6_add() {

In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do
route related jobs in a delayed workqueue . Hence, there is tiny period
we need to wait for it. Adding the `sleep 1` seems suffcient for now.

Signed-off-by: Su Yue <suy.fnst@fujitsu.com>
---
 testcases/network/mpls/mpls02.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh
index 2fd3ec5bf4ba..75f5fca32f9a 100755
--- a/testcases/network/mpls/mpls02.sh
+++ b/testcases/network/mpls/mpls02.sh
@@ -35,6 +35,8 @@ setup()
 	tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo"
 	tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)"
 	tst_rhost_run -s -c "ip -f mpls route add 50 dev lo"
+
+	sleep 1
 }
 
 do_test()
-- 
2.30.1 (Apple Git-130)


^ permalink raw reply related	[flat|nested] 12+ messages in thread
* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
  2021-08-26  5:26 [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 suy.fnst
@ 2021-08-26  9:36 ` Alexey Kodanev
  2021-08-30  6:46   ` suy.fnst
  2021-08-30  9:26   ` suy.fnst
  0 siblings, 2 replies; 12+ messages in thread
From: Alexey Kodanev @ 2021-08-26  9:36 UTC (permalink / raw)
  To: ltp

On 26.08.2021 08:26, suy.fnst@fujitsu.com wrote:
> While running mpls02.sh -6 in our slow test box with kernel
> version > v5.11, we found the test hangs at ping6 occasionally:
> 
>   + grep -q 'invalid option'
>   + for size in ${msg_sizes:-"56"}
>   + EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1
>   '>/dev/null'
>   + _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f
>   fd00:23::1 '>/dev/null'
>   + local fnc=tst_res
>   + shift
>   + tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null'
> 
> The weird part is that manual ping6 works in the meantime.
> 
> Then we found that adding `sleep 1` at end of mpls02.sh/setup() make
> the test pass in 100%. Dig depper in the problem, ftrace catched during
> the 1 second shows (The test started at [ 3979.485488]):
> 
>  3981.210701 |   2) kworker-24742  |               |  addrconf_dad_work() {
>  3981.210712 |   2) kworker-24742  |               |    addrconf_dad_completed() {
>  3981.210712 |   2) kworker-24742  |   0.417 us    |      addrconf_del_dad_work();
>  3981.210713 |   2) kworker-24742  |               |      __ipv6_ifa_notify() {
>  3981.210716 |   2) kworker-24742  |   1.097 us    |        inet6_fill_ifaddr();
>  3981.210730 |   2) kworker-24742  |               |        ip6_ins_rt() {
>  3981.210731 |   2) kworker-24742  |               |          fib6_add() {
> 
> In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do
> route related jobs in a delayed workqueue . Hence, there is tiny period
> we need to wait for it. Adding the `sleep 1` seems suffcient for now.

What is happening in the ping6, it is OK for it to hang on this?

Adding nodad to loopback might only change the flags (remove tentative
if ifa_flags==IFA_F_NODAD), the delayed dad work should be completed in
addrconf_dad_begin() for it anyway... but will it make any difference
for ping6 to change the test as below?

ip addr add $ip_loc/$mask dev lo nodad
tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo nodad"

> Signed-off-by: Su Yue <suy.fnst@fujitsu.com>
> ---
>  testcases/network/mpls/mpls02.sh | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh
> index 2fd3ec5bf4ba..75f5fca32f9a 100755
> --- a/testcases/network/mpls/mpls02.sh
> +++ b/testcases/network/mpls/mpls02.sh
> @@ -35,6 +35,8 @@ setup()
>  	tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo"
>  	tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)"
>  	tst_rhost_run -s -c "ip -f mpls route add 50 dev lo"
> +
> +	sleep 1
>  }
>  
>  do_test()
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
  2021-08-26  9:36 ` Alexey Kodanev
@ 2021-08-30  6:46   ` suy.fnst
  2021-08-30  9:26   ` suy.fnst
  1 sibling, 0 replies; 12+ messages in thread
From: suy.fnst @ 2021-08-30  6:46 UTC (permalink / raw)
  To: ltp

Hi, Alexey
  Sorry for late reply and the bad email format. 
  And thanks a lot for your suggestion! It inspire me to find the cause.
  I'll explain it in V2.

--
Su 

________________________________________
From: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Sent: Thursday, August 26, 2021 17:36
To: Su, Yue/? ?; ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02

On 26.08.2021 08:26, suy.fnst@fujitsu.com wrote:
> While running mpls02.sh -6 in our slow test box with kernel
> version > v5.11, we found the test hangs at ping6 occasionally:
>
>   + grep -q 'invalid option'
>   + for size in ${msg_sizes:-"56"}
>   + EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1
>   '>/dev/null'
>   + _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f
>   fd00:23::1 '>/dev/null'
>   + local fnc=tst_res
>   + shift
>   + tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null'
>
> The weird part is that manual ping6 works in the meantime.
>
> Then we found that adding `sleep 1` at end of mpls02.sh/setup() make
> the test pass in 100%. Dig depper in the problem, ftrace catched during
> the 1 second shows (The test started at [ 3979.485488]):
>
>  3981.210701 |   2) kworker-24742  |               |  addrconf_dad_work() {
>  3981.210712 |   2) kworker-24742  |               |    addrconf_dad_completed() {
>  3981.210712 |   2) kworker-24742  |   0.417 us    |      addrconf_del_dad_work();
>  3981.210713 |   2) kworker-24742  |               |      __ipv6_ifa_notify() {
>  3981.210716 |   2) kworker-24742  |   1.097 us    |        inet6_fill_ifaddr();
>  3981.210730 |   2) kworker-24742  |               |        ip6_ins_rt() {
>  3981.210731 |   2) kworker-24742  |               |          fib6_add() {
>
> In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do
> route related jobs in a delayed workqueue . Hence, there is tiny period
> we need to wait for it. Adding the `sleep 1` seems suffcient for now.

What is happening in the ping6, it is OK for it to hang on this?

Adding nodad to loopback might only change the flags (remove tentative
if ifa_flags==IFA_F_NODAD), the delayed dad work should be completed in
addrconf_dad_begin() for it anyway... but will it make any difference
for ping6 to change the test as below?

ip addr add $ip_loc/$mask dev lo nodad
tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo nodad"

> Signed-off-by: Su Yue <suy.fnst@fujitsu.com>
> ---
>  testcases/network/mpls/mpls02.sh | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh
> index 2fd3ec5bf4ba..75f5fca32f9a 100755
> --- a/testcases/network/mpls/mpls02.sh
> +++ b/testcases/network/mpls/mpls02.sh
> @@ -35,6 +35,8 @@ setup()
>       tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo"
>       tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)"
>       tst_rhost_run -s -c "ip -f mpls route add 50 dev lo"
> +
> +     sleep 1
>  }
>
>  do_test()
>


^ permalink raw reply	[flat|nested] 12+ messages in thread
* [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
  2021-08-26  9:36 ` Alexey Kodanev
  2021-08-30  6:46   ` suy.fnst
@ 2021-08-30  9:26   ` suy.fnst
  2021-09-09 15:53       ` pvorel
  1 sibling, 1 reply; 12+ messages in thread
From: suy.fnst @ 2021-08-30  9:26 UTC (permalink / raw)
  To: ltp

Hi,
  I found that it's indeed related to ipv6 DAD as you said.
Calling
`ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
or tst_wait_ipv6_dad() at end of the setup both solves the problem.
However there is one super strange part that the tentative address is
the local link adress of the ltp_ns_veth1:

5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.0.1/24 scope global ltp_ns_veth1
       valid_lft forever preferred_lft forever
    inet6 fd00:1:1:1::1/64 scope global nodad
       valid_lft forever preferred_lft forever
    inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative       <-------------------
       valid_lft forever preferred_lft forever

However, there is no place using the address in mpls02 test.
It makes me wonder how could it be possible to trigger the issue..

Thanks!
--
Su
________________________________________
From: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Sent: Thursday, August 26, 2021 17:36
To: Su, Yue/? ?; ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02

On 26.08.2021 08:26, suy.fnst@fujitsu.com wrote:
> While running mpls02.sh -6 in our slow test box with kernel
> version > v5.11, we found the test hangs at ping6 occasionally:
>
>   + grep -q 'invalid option'
>   + for size in ${msg_sizes:-"56"}
>   + EXPECT_PASS ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1
>   '>/dev/null'
>   + _tst_expect_pass tst_res ping6 -I fd00:23::2 -c 500 -s 10 -f
>   fd00:23::1 '>/dev/null'
>   + local fnc=tst_res
>   + shift
>   + tst_rod ping6 -I fd00:23::2 -c 500 -s 10 -f fd00:23::1 '>/dev/null'
>
> The weird part is that manual ping6 works in the meantime.
>
> Then we found that adding `sleep 1` at end of mpls02.sh/setup() make
> the test pass in 100%. Dig depper in the problem, ftrace catched during
> the 1 second shows (The test started at [ 3979.485488]):
>
>  3981.210701 |   2) kworker-24742  |               |  addrconf_dad_work() {
>  3981.210712 |   2) kworker-24742  |               |    addrconf_dad_completed() {
>  3981.210712 |   2) kworker-24742  |   0.417 us    |      addrconf_del_dad_work();
>  3981.210713 |   2) kworker-24742  |               |      __ipv6_ifa_notify() {
>  3981.210716 |   2) kworker-24742  |   1.097 us    |        inet6_fill_ifaddr();
>  3981.210730 |   2) kworker-24742  |               |        ip6_ins_rt() {
>  3981.210731 |   2) kworker-24742  |               |          fib6_add() {
>
> In kernel, addrconf_dad_work() is delegated by inet6_addr_add() to do
> route related jobs in a delayed workqueue . Hence, there is tiny period
> we need to wait for it. Adding the `sleep 1` seems suffcient for now.

What is happening in the ping6, it is OK for it to hang on this?

Adding nodad to loopback might only change the flags (remove tentative
if ifa_flags==IFA_F_NODAD), the delayed dad work should be completed in
addrconf_dad_begin() for it anyway... but will it make any difference
for ping6 to change the test as below?

ip addr add $ip_loc/$mask dev lo nodad
tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo nodad"

> Signed-off-by: Su Yue <suy.fnst@fujitsu.com>
> ---
>  testcases/network/mpls/mpls02.sh | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/testcases/network/mpls/mpls02.sh b/testcases/network/mpls/mpls02.sh
> index 2fd3ec5bf4ba..75f5fca32f9a 100755
> --- a/testcases/network/mpls/mpls02.sh
> +++ b/testcases/network/mpls/mpls02.sh
> @@ -35,6 +35,8 @@ setup()
>       tst_rhost_run -s -c "ip addr add $ip_rmt/$mask dev lo"
>       tst_rhost_run -s -c "ip route add $ip_loc/$mask encap mpls 60 via inet$TST_IPV6 $(tst_ipaddr)"
>       tst_rhost_run -s -c "ip -f mpls route add 50 dev lo"
> +
> +     sleep 1
>  }
>
>  do_test()
>


^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-09 15:53       ` pvorel
  2021-09-10  8:39           ` Alexey Kodanev
  0 siblings, 1 reply; 12+ messages in thread
From: pvorel @ 2021-09-09 15:53 UTC (permalink / raw)
  To: suy.fnst; +Cc: ltp

Hi Su, Alexey,

On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
> Hi,
>   I found that it's indeed related to ipv6 DAD as you said.
> Calling
> `ip netns exec ltp_ns sysctl -n 
> net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
> However there is one super strange part that the tentative address is
> the local link adress of the ltp_ns_veth1:
> 
> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP group default qlen 1000
>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>     inet 10.0.0.1/24 scope global ltp_ns_veth1
>        valid_lft forever preferred_lft forever
>     inet6 fd00:1:1:1::1/64 scope global nodad
>        valid_lft forever preferred_lft forever
>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
> <-------------------
>        valid_lft forever preferred_lft forever
> 
> However, there is no place using the address in mpls02 test.
> It makes me wonder how could it be possible to trigger the issue..

I wonder if test still needs be fixed to work on all setups.

Petr

> 
> Thanks!
> --
> Su

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-10  8:39           ` Alexey Kodanev
  2021-09-10  9:36               ` Petr Vorel
  2021-09-12  3:45               ` suy.fnst
  0 siblings, 2 replies; 12+ messages in thread
From: Alexey Kodanev @ 2021-09-10  8:39 UTC (permalink / raw)
  To: pvorel, suy.fnst; +Cc: ltp

On 09.09.2021 18:53, pvorel wrote:
> Hi Su, Alexey,
> 
> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
>> Hi,
>>   I found that it's indeed related to ipv6 DAD as you said.
>> Calling
>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
>> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
>> However there is one super strange part that the tentative address is
>> the local link adress of the ltp_ns_veth1:
>>
>> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>> state UP group default qlen 1000
>>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>     inet 10.0.0.1/24 scope global ltp_ns_veth1
>>        valid_lft forever preferred_lft forever
>>     inet6 fd00:1:1:1::1/64 scope global nodad
>>        valid_lft forever preferred_lft forever
>>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
>> <-------------------
>>        valid_lft forever preferred_lft forever
>>
>> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue..

Looks like the problem here in the neighbor discovery of fd00:1:1:1::2
using link-local address, and vice verse for the other side. mpls is
using the following route with the address:

fd00:23::2  encap mpls  60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium
so the address there should be in a reachable state...

Adding it manually in setup might fix the test as well:

ROD ip neigh replace $(tst_ipaddr rhost) lladdr $(tst_hwaddr rhost) dev $(tst_iface) nud reachable
tst_rhost_run -s -c "ip neigh replace $(tst_ipaddr) lladdr $(tst_hwaddr) dev $(tst_iface rhost) nud reachable"

> 
> I wonder if test still needs be fixed to work on all setups.
> 

I think we could set accept_dad to 0 in generic setup of the
test interfaces, in tst_net.sh/tst_init_iface().

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-10  9:36               ` Petr Vorel
  2021-09-13 11:14                   ` Alexey Kodanev
  0 siblings, 1 reply; 12+ messages in thread
From: Petr Vorel @ 2021-09-10  9:36 UTC (permalink / raw)
  To: Alexey Kodanev; +Cc: pvorel, suy.fnst, ltp

> On 09.09.2021 18:53, pvorel wrote:
> > Hi Su, Alexey,

> > On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
> >> Hi,
> >>   I found that it's indeed related to ipv6 DAD as you said.
> >> Calling
> >> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
> >> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
> >> However there is one super strange part that the tentative address is
> >> the local link adress of the ltp_ns_veth1:

> >> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> >> state UP group default qlen 1000
> >>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> >>     inet 10.0.0.1/24 scope global ltp_ns_veth1
> >>        valid_lft forever preferred_lft forever
> >>     inet6 fd00:1:1:1::1/64 scope global nodad
> >>        valid_lft forever preferred_lft forever
> >>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
> >> <-------------------
> >>        valid_lft forever preferred_lft forever

> >> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue..

> Looks like the problem here in the neighbor discovery of fd00:1:1:1::2
> using link-local address, and vice verse for the other side. mpls is
> using the following route with the address:

> fd00:23::2  encap mpls  60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium
> so the address there should be in a reachable state...

Thanks for info! I wonder if it's a bug in mpls or elsewhere. WDYT?

> Adding it manually in setup might fix the test as well:

> ROD ip neigh replace $(tst_ipaddr rhost) lladdr $(tst_hwaddr rhost) dev $(tst_iface) nud reachable
> tst_rhost_run -s -c "ip neigh replace $(tst_ipaddr) lladdr $(tst_hwaddr) dev $(tst_iface rhost) nud reachable"

> > I wonder if test still needs be fixed to work on all setups.


> I think we could set accept_dad to 0 in generic setup of the
> test interfaces, in tst_net.sh/tst_init_iface().
Unless it's a bug we'd hide by setting it, I'd be for this general solution.

It'd be nice to get it fixed before release.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-12  3:45               ` suy.fnst
  0 siblings, 0 replies; 12+ messages in thread
From: suy.fnst @ 2021-09-12  3:45 UTC (permalink / raw)
  To: Alexey Kodanev, pvorel; +Cc: ltp

Hi, Alexey
  Thanks! It works! Could you send a patch for the fix?
  You can add my
  Tested-by: Su Yue <suy.fnst@fujitsu.com>


--
Su

________________________________________
From: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Sent: Friday, September 10, 2021 16:39
To: pvorel; Su, Yue/苏 越
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02

On 09.09.2021 18:53, pvorel wrote:
> Hi Su, Alexey,
>
> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
>> Hi,
>>   I found that it's indeed related to ipv6 DAD as you said.
>> Calling
>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
>> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
>> However there is one super strange part that the tentative address is
>> the local link adress of the ltp_ns_veth1:
>>
>> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>> state UP group default qlen 1000
>>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>     inet 10.0.0.1/24 scope global ltp_ns_veth1
>>        valid_lft forever preferred_lft forever
>>     inet6 fd00:1:1:1::1/64 scope global nodad
>>        valid_lft forever preferred_lft forever
>>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
>> <-------------------
>>        valid_lft forever preferred_lft forever
>>
>> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue..

Looks like the problem here in the neighbor discovery of fd00:1:1:1::2
using link-local address, and vice verse for the other side. mpls is
using the following route with the address:

fd00:23::2  encap mpls  60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium
so the address there should be in a reachable state...

Adding it manually in setup might fix the test as well:

ROD ip neigh replace $(tst_ipaddr rhost) lladdr $(tst_hwaddr rhost) dev $(tst_iface) nud reachable
tst_rhost_run -s -c "ip neigh replace $(tst_ipaddr) lladdr $(tst_hwaddr) dev $(tst_iface rhost) nud reachable"

>
> I wonder if test still needs be fixed to work on all setups.
>

I think we could set accept_dad to 0 in generic setup of the
test interfaces, in tst_net.sh/tst_init_iface().

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-13 11:14                   ` Alexey Kodanev
  2021-09-13 12:28                       ` Petr Vorel
  0 siblings, 1 reply; 12+ messages in thread
From: Alexey Kodanev @ 2021-09-13 11:14 UTC (permalink / raw)
  To: Petr Vorel; +Cc: pvorel, suy.fnst, ltp

Hi Petr,
On 10.09.2021 12:36, Petr Vorel wrote:
>> On 09.09.2021 18:53, pvorel wrote:
>>> Hi Su, Alexey,
> 
>>> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
>>>> Hi,
>>>>   I found that it's indeed related to ipv6 DAD as you said.
>>>> Calling
>>>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
>>>> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
>>>> However there is one super strange part that the tentative address is
>>>> the local link adress of the ltp_ns_veth1:
> 
>>>> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>> state UP group default qlen 1000
>>>>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>>>     inet 10.0.0.1/24 scope global ltp_ns_veth1
>>>>        valid_lft forever preferred_lft forever
>>>>     inet6 fd00:1:1:1::1/64 scope global nodad
>>>>        valid_lft forever preferred_lft forever
>>>>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
>>>> <-------------------
>>>>        valid_lft forever preferred_lft forever
> 
>>>> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue..
> 
>> Looks like the problem here in the neighbor discovery of fd00:1:1:1::2
>> using link-local address, and vice verse for the other side. mpls is
>> using the following route with the address:
> 
>> fd00:23::2  encap mpls  60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium
>> so the address there should be in a reachable state...
> 
> Thanks for info! I wonder if it's a bug in mpls or elsewhere. WDYT?

https://github.com/iputils/iputils/issues/300

So we should be careful with the flood option in ping, especially
if it is the first test to run after initial test interfaces setup.
For example, for mpls02, it is "icmp tcp udp".

> 
>> Adding it manually in setup might fix the test as well:
> 
>> ROD ip neigh replace $(tst_ipaddr rhost) lladdr $(tst_hwaddr rhost) dev $(tst_iface) nud reachable
>> tst_rhost_run -s -c "ip neigh replace $(tst_ipaddr) lladdr $(tst_hwaddr) dev $(tst_iface rhost) nud reachable"
> 
>>> I wonder if test still needs be fixed to work on all setups.
> 
> 
>> I think we could set accept_dad to 0 in generic setup of the
>> test interfaces, in tst_net.sh/tst_init_iface().
> Unless it's a bug we'd hide by setting it, I'd be for this general solution.
> 
> It'd be nice to get it fixed before release.

OK


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-13 12:28                       ` Petr Vorel
  2021-09-13 12:38                           ` Alexey Kodanev
  0 siblings, 1 reply; 12+ messages in thread
From: Petr Vorel @ 2021-09-13 12:28 UTC (permalink / raw)
  To: Alexey Kodanev; +Cc: suy.fnst, ltp

> Hi Petr,
> On 10.09.2021 12:36, Petr Vorel wrote:
> >> On 09.09.2021 18:53, pvorel wrote:
> >>> Hi Su, Alexey,

> >>> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
> >>>> Hi,
> >>>>   I found that it's indeed related to ipv6 DAD as you said.
> >>>> Calling
> >>>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
> >>>> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
> >>>> However there is one super strange part that the tentative address is
> >>>> the local link adress of the ltp_ns_veth1:

> >>>> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> >>>> state UP group default qlen 1000
> >>>>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> >>>>     inet 10.0.0.1/24 scope global ltp_ns_veth1
> >>>>        valid_lft forever preferred_lft forever
> >>>>     inet6 fd00:1:1:1::1/64 scope global nodad
> >>>>        valid_lft forever preferred_lft forever
> >>>>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
> >>>> <-------------------
> >>>>        valid_lft forever preferred_lft forever

> >>>> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue..

> >> Looks like the problem here in the neighbor discovery of fd00:1:1:1::2
> >> using link-local address, and vice verse for the other side. mpls is
> >> using the following route with the address:

> >> fd00:23::2  encap mpls  60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium
> >> so the address there should be in a reachable state...

> > Thanks for info! I wonder if it's a bug in mpls or elsewhere. WDYT?

> https://github.com/iputils/iputils/issues/300
Ah, thanks for pointing this.

> So we should be careful with the flood option in ping, especially
> if it is the first test to run after initial test interfaces setup.
> For example, for mpls02, it is "icmp tcp udp".
Flooding is done with -f or -i 0. IMHO we don't do that in tst_ping(),
what am I missing? The bug is about flooding (-i 0) with zero packet size (-s 0,
but maybe our use -s 10 would trigger the bug as well).

Kind regards,
Petr


> >> Adding it manually in setup might fix the test as well:

> >> ROD ip neigh replace $(tst_ipaddr rhost) lladdr $(tst_hwaddr rhost) dev $(tst_iface) nud reachable
> >> tst_rhost_run -s -c "ip neigh replace $(tst_ipaddr) lladdr $(tst_hwaddr) dev $(tst_iface rhost) nud reachable"

> >>> I wonder if test still needs be fixed to work on all setups.


> >> I think we could set accept_dad to 0 in generic setup of the
> >> test interfaces, in tst_net.sh/tst_init_iface().
> > Unless it's a bug we'd hide by setting it, I'd be for this general solution.

> > It'd be nice to get it fixed before release.

> OK


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-13 12:38                           ` Alexey Kodanev
  2021-09-13 12:55                               ` Petr Vorel
  0 siblings, 1 reply; 12+ messages in thread
From: Alexey Kodanev @ 2021-09-13 12:38 UTC (permalink / raw)
  To: Petr Vorel; +Cc: suy.fnst, ltp

On 13.09.2021 15:28, Petr Vorel wrote:
>> Hi Petr,
>> On 10.09.2021 12:36, Petr Vorel wrote:
>>>> On 09.09.2021 18:53, pvorel wrote:
>>>>> Hi Su, Alexey,
> 
>>>>> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
>>>>>> Hi,
>>>>>>   I found that it's indeed related to ipv6 DAD as you said.
>>>>>> Calling
>>>>>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
>>>>>> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
>>>>>> However there is one super strange part that the tentative address is
>>>>>> the local link adress of the ltp_ns_veth1:
> 
>>>>>> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>>>> state UP group default qlen 1000
>>>>>>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>>>>>>     inet 10.0.0.1/24 scope global ltp_ns_veth1
>>>>>>        valid_lft forever preferred_lft forever
>>>>>>     inet6 fd00:1:1:1::1/64 scope global nodad
>>>>>>        valid_lft forever preferred_lft forever
>>>>>>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
>>>>>> <-------------------
>>>>>>        valid_lft forever preferred_lft forever
> 
>>>>>> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue..
> 
>>>> Looks like the problem here in the neighbor discovery of fd00:1:1:1::2
>>>> using link-local address, and vice verse for the other side. mpls is
>>>> using the following route with the address:
> 
>>>> fd00:23::2  encap mpls  60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium
>>>> so the address there should be in a reachable state...
> 
>>> Thanks for info! I wonder if it's a bug in mpls or elsewhere. WDYT?
> 
>> https://github.com/iputils/iputils/issues/300
> Ah, thanks for pointing this.
> 
>> So we should be careful with the flood option in ping, especially
>> if it is the first test to run after initial test interfaces setup.
>> For example, for mpls02, it is "icmp tcp udp".
> Flooding is done with -f or -i 0. IMHO we don't do that in tst_ping(),
> what am I missing? The bug is about flooding (-i 0) with zero packet size (-s 0,
> but maybe our use -s 10 would trigger the bug as well).

Actually, we do have -f option in tst_ping(), in $flood_opt var.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02
@ 2021-09-13 12:55                               ` Petr Vorel
  0 siblings, 0 replies; 12+ messages in thread
From: Petr Vorel @ 2021-09-13 12:55 UTC (permalink / raw)
  To: Alexey Kodanev; +Cc: suy.fnst, ltp

> On 13.09.2021 15:28, Petr Vorel wrote:
> >> Hi Petr,
> >> On 10.09.2021 12:36, Petr Vorel wrote:
> >>>> On 09.09.2021 18:53, pvorel wrote:
> >>>>> Hi Su, Alexey,

> >>>>> On 2021-08-30 11:26, suy.fnst@fujitsu.com wrote:
> >>>>>> Hi,
> >>>>>>   I found that it's indeed related to ipv6 DAD as you said.
> >>>>>> Calling
> >>>>>> `ip netns exec ltp_ns sysctl -n net.ipv6.conf.ltp_ns_veth1.accept_dad=0`
> >>>>>> or tst_wait_ipv6_dad() at end of the setup both solves the problem.
> >>>>>> However there is one super strange part that the tentative address is
> >>>>>> the local link adress of the ltp_ns_veth1:

> >>>>>> 5: ltp_ns_veth1@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> >>>>>> state UP group default qlen 1000
> >>>>>>     link/ether f2:8f:24:d4:ba:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> >>>>>>     inet 10.0.0.1/24 scope global ltp_ns_veth1
> >>>>>>        valid_lft forever preferred_lft forever
> >>>>>>     inet6 fd00:1:1:1::1/64 scope global nodad
> >>>>>>        valid_lft forever preferred_lft forever
> >>>>>>     inet6 fe80::f08f:24ff:fed4:ba26/64 scope link tentative
> >>>>>> <-------------------
> >>>>>>        valid_lft forever preferred_lft forever

> >>>>>> However, there is no place using the address in mpls02 test.>> It makes me wonder how could it be possible to trigger the issue..

> >>>> Looks like the problem here in the neighbor discovery of fd00:1:1:1::2
> >>>> using link-local address, and vice verse for the other side. mpls is
> >>>> using the following route with the address:

> >>>> fd00:23::2  encap mpls  60 via fd00:1:1:1::2 dev ltp_ns_veth1 metric 1024 pref medium
> >>>> so the address there should be in a reachable state...

> >>> Thanks for info! I wonder if it's a bug in mpls or elsewhere. WDYT?

> >> https://github.com/iputils/iputils/issues/300
> > Ah, thanks for pointing this.

> >> So we should be careful with the flood option in ping, especially
> >> if it is the first test to run after initial test interfaces setup.
> >> For example, for mpls02, it is "icmp tcp udp".
> > Flooding is done with -f or -i 0. IMHO we don't do that in tst_ping(),
> > what am I missing? The bug is about flooding (-i 0) with zero packet size (-s 0,
> > but maybe our use -s 10 would trigger the bug as well).

> Actually, we do have -f option in tst_ping(), in $flood_opt var.
Ah, I'm blind today, thanks :). I wonder if it's really enough for mpls to just
move icmp in TST_TEST_DATA to the end (or just not being first). If it's
working, feel free to add ack from my to the commit message.

Kind regards,
Petr


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-09-13 12:56 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-26  5:26 [LTP] [PATCH] network/mpls: sleep 1 after setup in mpls02 suy.fnst
2021-08-26  9:36 ` Alexey Kodanev
2021-08-30  6:46   ` suy.fnst
2021-08-30  9:26   ` suy.fnst
2021-09-09 15:53     ` pvorel
2021-09-09 15:53       ` pvorel
2021-09-10  8:39         ` Alexey Kodanev
2021-09-10  8:39           ` Alexey Kodanev
2021-09-10  9:36             ` Petr Vorel
2021-09-10  9:36               ` Petr Vorel
2021-09-13 11:14                 ` Alexey Kodanev
2021-09-13 11:14                   ` Alexey Kodanev
2021-09-13 12:28                     ` Petr Vorel
2021-09-13 12:28                       ` Petr Vorel
2021-09-13 12:38                         ` Alexey Kodanev
2021-09-13 12:38                           ` Alexey Kodanev
2021-09-13 12:55                             ` Petr Vorel
2021-09-13 12:55                               ` Petr Vorel
2021-09-12  3:45             ` suy.fnst
2021-09-12  3:45               ` suy.fnst

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.