[net,v2,2/2] selftests: pmtu: add explicit tests for PMTU exceptions cleanup

Add a couple of new tests, explicitly checking that the kernel
timely releases PMTU exceptions on related device removal.
This is mostly a regression test vs the issue fixed by
commit f5b51fe804ec ("ipv6: route: purge exception on removal")

Only 2 new test cases have been added, instead of extending all
the existing ones, because the reproducer requires executing
several commands and would slow down too much the tests otherwise.

v1 -> v2:
 - several script cleanups, as suggested by Stefano

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 tools/testing/selftests/net/pmtu.sh | 67 ++++++++++++++++++++++++++++-
 1 file changed, 66 insertions(+), 1 deletion(-)

Just three minor details, feel free to ignore:

On Mon, 25 Feb 2019 12:13:46 +0100
Paolo Abeni <pabeni@redhat.com> wrote:

> @@ -1006,6 +1017,60 @@ test_pmtu_vti6_link_change_mtu() {
>  	return ${fail}
>  }
>  
> +chk_command() {

All the other functions checking something are called 'check_*'.

> +	cmd=${1}
> +
> +	if ! which ${cmd} > /dev/null 2>&1; then
> +		err "  missing required command: '${cmd}'"
> +		return 1
> +	fi
> +	return 0
> +}
> +
> +test_cleanup_vxlanX_exception() {
> +	outer="${1}"
> +	encap="vxlan"
> +	ll_mtu=4000
> +
> +	chk_command taskset || return 2
> +	chk_command timeout || return 2
> +	cpu_list=$(grep -m 2 processor /proc/cpuinfo | cut -d ' ' -f 2)
> +
> +	setup namespaces routing ${encap}${outer} || return 2
> +	trace "${ns_a}" ${encap}_a   "${ns_b}"  ${encap}_b \
> +	      "${ns_a}" veth_A-R1    "${ns_r1}" veth_R1-A \
> +	      "${ns_b}" veth_B-R1    "${ns_r1}" veth_R1-B
> +
> +	# Create route exception by exceeding link layer MTU
> +	mtu "${ns_a}"  veth_A-R1 $((${ll_mtu} + 1000))
> +	mtu "${ns_r1}" veth_R1-A $((${ll_mtu} + 1000))
> +	mtu "${ns_b}"  veth_B-R1 ${ll_mtu}
> +	mtu "${ns_r1}" veth_R1-B ${ll_mtu}
> +
> +	mtu "${ns_a}" ${encap}_a $((${ll_mtu} + 1000))
> +	mtu "${ns_b}" ${encap}_b $((${ll_mtu} + 1000))
> +
> +	# Fill exception cache for multiple CPUs (2)
> +	# we can always use inner IPv4 for that
> +	for cpu in ${cpu_list}; do
> +		taskset --cpu-list ${cpu} ${ns_a} ping -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${tunnel4_b_addr} > /dev/null
> +	done
> +
> +	if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then
> +		err "  can't delete veth device in a timely manner, PMTU dst likely leaked"
> +		return 1
> +	fi
> +	return 0

No need for explicit return 0.

> +}
> +
> +test_pmtu_ipv6_exception_cleanup() {
> +	test_cleanup_vxlanX_exception 6 vxlan
> +}
> +
> +test_pmtu_ipv4_exception_cleanup() {
> +	test_cleanup_vxlanX_exception 4 vxlan

This function now takes just one argument.

2019-02-25, 12:13:46 +0100, Paolo Abeni wrote:
> +	if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then

That doesn't work. "ip link del" is stuck in a way that timeout can't
terminate it, so this is still going to hang. Did you actually test
this? :/

> +		err "  can't delete veth device in a timely manner, PMTU dst likely leaked"
> +		return 1
> +	fi
> +	return 0
> +}

On Mon, 25 Feb 2019 13:33:30 +0100
Sabrina Dubroca <sd@queasysnail.net> wrote:

> 2019-02-25, 12:13:46 +0100, Paolo Abeni wrote:
> > +	if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then  
> 
> That doesn't work. "ip link del" is stuck in a way that timeout can't
> terminate it, so this is still going to hang. Did you actually test
> this? :/

Indeed, upon actual testing, this hangs and the error is not reported.

> > +		err "  can't delete veth device in a timely
> > manner, PMTU dst likely leaked"
> > +		return 1
> > +	fi
> > +	return 0
> > +}  

You can use a subshell here, something like:

	${ns_a} ip link del dev veth_A-R1 &
	iplink_pid=$!
	sleep 1
	if [ "$(cat /proc/${iplink_pid}/cmdline 2>/dev/null | tr -d '\0')" = "iplinkdeldevveth_A-R1" ]; then
		err "  can't delete veth device in a timely manner, PMTU dst likely leaked"
		return 1
	fi
}

and now that I tried to run as a single test and couldn't find it, I
think it would also be worth it to rename the tests to something more
sensible.

Right now you have test_pmtu_ipv6_exception_cleanup() calling
test_cleanup_...(), I think it's confusing. Just call the test
test_cleanup_ipv6_exception(), it doesn't have so much to do with PMTU
anyway.