public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Rue <dan.rue@linaro.org>
To: ltp@lists.linux.it
Cc: mmarhefk@redhat.com, netdev@vger.kernel.org
Subject: Re: [RFC] [PATCH] netns: Fix race in virtual interface bringup
Date: Wed, 15 Nov 2017 13:04:23 -0600	[thread overview]
Message-ID: <20171115190423.kcrzl2odqtdr6ghg@xps> (raw)
In-Reply-To: <20171109203841.28856-1-dan.rue@linaro.org>

Adding CC netdev

Can someone comment on the expected behavior of this test case?

Here's the isolated test:

    ip netns del tst_net_ns0
    ip netns del tst_net_ns1
    ip netns add tst_net_ns0
    ip netns add tst_net_ns1
    ip netns exec tst_net_ns0 ip link add veth0 type veth peer name veth1
    ip netns exec tst_net_ns0 ip link set veth1 netns tst_net_ns1

    ip netns exec tst_net_ns0 ifconfig veth0 inet6 add fd00::2/64
    ip netns exec tst_net_ns1 ifconfig veth1 inet6 add fd00::3/64
    ip netns exec tst_net_ns0 ifconfig veth0 up
    ip netns exec tst_net_ns1 ifconfig veth1 up

    #sleep 2

    ip netns exec tst_net_ns0 ping6 -q -c2 -I veth0 fd00::3

This is essentially what LTP is running. Sometimes, on some systems,
ping6 fails with "connect: Cannot assign requested address". Adding a
"sleep 2" always fixes it (but we'd obviously like to avoid a hard coded
sleep in the test).

Questions:
1) Is the behavior of "ifconfig up" intentionally asynchronous (I
believe so, based on dmesg)? If so, what is the correct way to find out
when the interface is available?

Thank you!
Dan

On Thu, Nov 09, 2017 at 02:38:41PM -0600, Dan Rue wrote:
> Symptoms (+ command, error):
>     netns_comm_ip_ipv6_ioctl:
>         + ip netns exec tst_net_ns1 ping6 -q -c2 -I veth1 fd00::2
>         connect: Cannot assign requested address
> 
>     netns_comm_ip_ipv6_netlink:
>         + ip netns exec tst_net_ns0 ping6 -q -c2 -I veth0 fd00::3
>         connect: Cannot assign requested address
> 
>     netns_comm_ns_exec_ipv6_ioctl:
>         + ns_exec 6689 net ping6 -q -c2 -I veth0 fd00::3
>         connect: Cannot assign requested address
> 
>     netns_comm_ns_exec_ipv6_netlin:
>         + ns_exec 6891 net ping6 -q -c2 -I veth0 fd00::3
>         connect: Cannot assign requested address
> 
> The error is coming from ping6, which is trying to get an IP address for
> veth0 (due to -I veth0), but cannot. Waiting for two seconds fixes the
> test in my testcases. 1 second is not long enough.
> 
> dmesg shows the following during the test:
> 
>     [Nov 7 15:39] LTP: starting netns_comm_ip_ipv6_ioctl (netns_comm.sh ip ipv6 ioctl)
>     [  +0.302401] IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready
>     [  +0.048059] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
> 
> Signed-off-by: Dan Rue <dan.rue@linaro.org>
> ---
> 
> We've periodically hit this problem across many arm64 kernels and boards, and
> it seems to be caused by "ping6" running before the virtual interface is
> actually ready. "sleep 2" works around the issue and proves that it is a race
> condition, but I would prefer something faster and deterministic. Please
> suggest a better implementation.
> 
> Also, is it correct that "ifconfig veth0 up" returns before the interface is
> actually ready?
> 
> See also this isolated test script:
> https://gist.github.com/danrue/7b76bbcbc23a6296030b7295650b69f3
> 
>  testcases/kernel/containers/netns/netns_helper.sh | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/testcases/kernel/containers/netns/netns_helper.sh b/testcases/kernel/containers/netns/netns_helper.sh
> index a95cdf206..99172c0c0 100755
> --- a/testcases/kernel/containers/netns/netns_helper.sh
> +++ b/testcases/kernel/containers/netns/netns_helper.sh
> @@ -285,6 +285,7 @@ netns_set_ip()
>  			tst_brkm TBROK "enabling veth1 device failed"
>  		;;
>  	esac
> +	sleep 2
>  }
>  
>  netns_ns_exec_cleanup()
> -- 
> 2.13.6
> 

       reply	other threads:[~2017-11-15 19:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20171109203841.28856-1-dan.rue@linaro.org>
2017-11-15 19:04 ` Dan Rue [this message]
2017-11-16  9:56   ` [RFC] [PATCH] netns: Fix race in virtual interface bringup Nicolas Dichtel
2017-11-21 21:12     ` [LTP] " Dan Rue
     [not found] ` <CAEemH2eiHo8EfyMqVhS=iee8Hfxw7_ygeKtGHBo_AFGW1QEYGw@mail.gmail.com>
     [not found]   ` <2c722239-8e24-9796-a022-03b0c423f3b8@oracle.com>
2017-11-17 22:29     ` Dan Rue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171115190423.kcrzl2odqtdr6ghg@xps \
    --to=dan.rue@linaro.org \
    --cc=ltp@lists.linux.it \
    --cc=mmarhefk@redhat.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox