diff mbox series

[2/2] testcases: netns: Handle "Operation not supported" error

Message ID 20180802141251.1571-2-mylene.josserand@bootlin.com
State Changes Requested
Delegated to: Petr Vorel
Headers show
Series [1/2] testcases: netns: Check TUN support enabled | expand

Commit Message

Mylène Josserand Aug. 2, 2018, 2:12 p.m. UTC 
If there is no support for "dummy" or "veth", the tests will fail
with errors:
   RTNETLINK answers: Operation not supported
   netns_sysfs 1 TBROK: failed to add a new (host) dummy device
and
   RTNETLINK answers: Operation not supported
   netns_comm_ip_ipv6_ioctl 1 TBROK: unable to create veth pair devices
   Cannot find device "veth0"

This commit is storing the output of the commands and verifies
if there is any reference to "Operation not supported".
This code is based on what it is already done in "ipsec_lib.sh"
stress test.

Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
---
 testcases/kernel/containers/netns/netns_helper.sh | 16 ++++++++++++++--
 testcases/kernel/containers/netns/netns_sysfs.sh  |  6 +++++-
 2 files changed, 19 insertions(+), 3 deletions(-)

Comments

Alexey Kodanev Aug. 8, 2018, 11:16 a.m. UTC | #1 
On 02.08.2018 17:12, Mylène Josserand wrote:
> If there is no support for "dummy" or "veth", the tests will fail
> with errors:
>    RTNETLINK answers: Operation not supported
>    netns_sysfs 1 TBROK: failed to add a new (host) dummy device
> and
>    RTNETLINK answers: Operation not supported
>    netns_comm_ip_ipv6_ioctl 1 TBROK: unable to create veth pair devices
>    Cannot find device "veth0"
> 
> This commit is storing the output of the commands and verifies
> if there is any reference to "Operation not supported".
> This code is based on what it is already done in "ipsec_lib.sh"
> stress test.

Not sure if the same should be here. The test-cases with IPsec involve
various crypto drivers that are much easier and better to check with
ip/netlink, and we also check both: the support in iproute and kernel.
I guess, veth and dummy virtual drivers could be checked with:
  
   modprobe -q veth || tst_brkm TCONF ...

Perhaps, we could add tst_drivers_available() helper to the library.

Thanks,
Alexey

> 
> Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
> ---
>  testcases/kernel/containers/netns/netns_helper.sh | 16 ++++++++++++++--
>  testcases/kernel/containers/netns/netns_sysfs.sh  |  6 +++++-
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/testcases/kernel/containers/netns/netns_helper.sh b/testcases/kernel/containers/netns/netns_helper.sh
> index 6aea10b47..58be60148 100755
> --- a/testcases/kernel/containers/netns/netns_helper.sh
> +++ b/testcases/kernel/containers/netns/netns_helper.sh
> @@ -199,8 +199,14 @@ netns_ns_exec_setup()
>  		tst_brkm TBROK "unable to create a new network namespace"
>  	fi
>  
> -	$NS_EXEC $NS_HANDLE0 $NS_TYPE ip link add veth0 type veth peer name veth1 || \
> +	local output=$($NS_EXEC $NS_HANDLE0 $NS_TYPE ip link add veth0 type \
> +				veth peer name veth1 2>&1 || echo 'TERR')
> +	if echo "$output" | grep -q "TERR"; then
> +		echo "$output" | grep -q \
> +			'RTNETLINK answers: Operation not supported' && \
> +			tst_brkm TCONF "Command not supported (maybe missing 'veth' support)"
>  		tst_brkm TBROK "unable to create veth pair devices"
> +	fi
>  
>  	$NS_EXEC $NS_HANDLE0 $NS_TYPE ns_ifmove veth1 $NS_HANDLE1
>  	ret=$?
> @@ -235,8 +241,14 @@ netns_ip_setup()
>  	ip netns add $NS_HANDLE1 || \
>  		tst_brkm TBROK "unable to create a new network namespace"
>  
> -	$NS_EXEC $NS_HANDLE0 ip link add veth0 type veth peer name veth1 || \
> +	local output=$($NS_EXEC $NS_HANDLE0 ip link add veth0 type \
> +				veth peer name veth1 2>&1 || echo 'TERR')
> +	if echo "$output" | grep -q "TERR"; then
> +		echo "$output" | grep -q \
> +			'RTNETLINK answers: Operation not supported' && \
> +			tst_brkm TCONF "Command not supported (maybe missing 'veth' support)"
>  		tst_brkm TBROK "unable to create veth pair devices"
> +	fi
>  
>  	$NS_EXEC $NS_HANDLE0 ip link set veth1 netns $NS_HANDLE1 || \
>  		tst_brkm TBROK "unable to add device veth1 to the separate network namespace"
> diff --git a/testcases/kernel/containers/netns/netns_sysfs.sh b/testcases/kernel/containers/netns/netns_sysfs.sh
> index 944a4c152..138d11402 100644
> --- a/testcases/kernel/containers/netns/netns_sysfs.sh
> +++ b/testcases/kernel/containers/netns/netns_sysfs.sh
> @@ -54,8 +54,12 @@ if [ $? -eq 1 ]; then
>  fi
>  TST_CLEANUP=cleanup
>  
> -ip link add $DUMMYDEV_HOST type dummy || \
> +output=$(ip link add $DUMMYDEV_HOST type dummy 2>&1 || echo 'TERR')
> +if echo "$output" | grep -q "TERR"; then
> +	echo "$output" | grep -q 'RTNETLINK answers: Operation not supported' && \
> +		tst_brkm TCONF "Command not supported (maybe missing 'dummy' support)"
>  	tst_brkm TBROK "failed to add a new (host) dummy device"
> +fi
>  
>  ns_exec $NS_HANDLE $NS_TYPE mount --make-rprivate /sys
>  ns_exec $NS_HANDLE $NS_TYPE ip link add $DUMMYDEV type dummy || \
>
Cyril Hrubis Aug. 8, 2018, 1:05 p.m. UTC | #2 
Hi!
> Not sure if the same should be here. The test-cases with IPsec involve
> various crypto drivers that are much easier and better to check with
> ip/netlink, and we also check both: the support in iproute and kernel.
> I guess, veth and dummy virtual drivers could be checked with:
>   
>    modprobe -q veth || tst_brkm TCONF ...

That will possibly break on embedded systems that have everything
compiled-in kernel, not sure if there are any out there.

> Perhaps, we could add tst_drivers_available() helper to the library.

That's a good idea, that way it could be at least tweaked in a single
place.
Thomas Petazzoni Aug. 8, 2018, 1:31 p.m. UTC | #3 
Hello,

On Wed, 8 Aug 2018 15:05:12 +0200, Cyril Hrubis wrote:

> > Not sure if the same should be here. The test-cases with IPsec involve
> > various crypto drivers that are much easier and better to check with
> > ip/netlink, and we also check both: the support in iproute and kernel.
> > I guess, veth and dummy virtual drivers could be checked with:
> >   
> >    modprobe -q veth || tst_brkm TCONF ...  
> 
> That will possibly break on embedded systems that have everything
> compiled-in kernel, not sure if there are any out there.

Perhaps LTP should require the kernel to be compiled with
CONFIG_IKCONFIG_PROC=y, so that LTP tests can check in /proc/config.gz
whether a given kernel feature is available or not ?

Best regards,

Thomas
Alexey Kodanev Aug. 8, 2018, 1:53 p.m. UTC | #4 
On 08/08/2018 04:05 PM, Cyril Hrubis wrote:
> Hi!
>> Not sure if the same should be here. The test-cases with IPsec involve
>> various crypto drivers that are much easier and better to check with
>> ip/netlink, and we also check both: the support in iproute and kernel.
>> I guess, veth and dummy virtual drivers could be checked with:
>>   
>>    modprobe -q veth || tst_brkm TCONF ...
> 
> That will possibly break on embedded systems that have everything
> compiled-in kernel, not sure if there are any out there.

modprobe looks for modules.builtin as well and will just return 0 if
it finds the driver there. But it might not be available for kernels
before 2.6.33: bc081dd6e9f6 ("kbuild: generate modules.builtin").

> 
>> Perhaps, we could add tst_drivers_available() helper to the library.
> 
> That's a good idea, that way it could be at least tweaked in a single
> place.
>
Cyril Hrubis Aug. 8, 2018, 2:06 p.m. UTC | #5 
Hi!
> > That will possibly break on embedded systems that have everything
> > compiled-in kernel, not sure if there are any out there.
> 
> Perhaps LTP should require the kernel to be compiled with
> CONFIG_IKCONFIG_PROC=y, so that LTP tests can check in /proc/config.gz
> whether a given kernel feature is available or not ?

The problem is that several major distributions does not do that, so
it's not an option.
Cyril Hrubis Aug. 8, 2018, 2:08 p.m. UTC | #6 
Hi!
> > That will possibly break on embedded systems that have everything
> > compiled-in kernel, not sure if there are any out there.
> 
> modprobe looks for modules.builtin as well and will just return 0 if
> it finds the driver there. But it might not be available for kernels
> before 2.6.33: bc081dd6e9f6 ("kbuild: generate modules.builtin").

I was also thinking of embedded hardware that does not even install
modprobe, but maybe I'm overthinking it and such special cases will have
to manualy specify what is supported and what is not, which would be at
least doable if we added a library function for checking what is
suppored.
Petr Vorel Oct. 4, 2018, 1:06 p.m. UTC | #7 
Hi Mylène,

> If there is no support for "dummy" or "veth", the tests will fail
> with errors:
>    RTNETLINK answers: Operation not supported
>    netns_sysfs 1 TBROK: failed to add a new (host) dummy device
> and
>    RTNETLINK answers: Operation not supported
>    netns_comm_ip_ipv6_ioctl 1 TBROK: unable to create veth pair devices
>    Cannot find device "veth0"

> This commit is storing the output of the commands and verifies
> if there is any reference to "Operation not supported".
> This code is based on what it is already done in "ipsec_lib.sh"
> stress test.

> Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>

..
> diff --git a/testcases/kernel/containers/netns/netns_helper.sh b/testcases/kernel/containers/netns/netns_helper.sh
...
> +			tst_brkm TCONF "Command not supported (maybe missing 'veth' support)"

..
> diff --git a/testcases/kernel/containers/netns/netns_sysfs.sh b/testcases/kernel/containers/netns/netns_sysfs.sh
..
> +		tst_brkm TCONF "Command not supported (maybe missing 'dummy' support)"

Can you implement this patch with TST_NEEDS_DRIVERS (recently contributed by
Alexey Kodanev)? Thanks a lot!


Kind regards,
Petr
Mylène Josserand Oct. 8, 2018, 9:28 a.m. UTC | #8 
Hello,

On Thu, 4 Oct 2018 15:06:11 +0200
Petr Vorel <pvorel@suse.cz> wrote:

> Hi Mylène,
> 
> > If there is no support for "dummy" or "veth", the tests will fail
> > with errors:
> >    RTNETLINK answers: Operation not supported
> >    netns_sysfs 1 TBROK: failed to add a new (host) dummy device
> > and
> >    RTNETLINK answers: Operation not supported
> >    netns_comm_ip_ipv6_ioctl 1 TBROK: unable to create veth pair devices
> >    Cannot find device "veth0"  
> 
> > This commit is storing the output of the commands and verifies
> > if there is any reference to "Operation not supported".
> > This code is based on what it is already done in "ipsec_lib.sh"
> > stress test.  
> 
> > Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>  
> 
> ..
> > diff --git a/testcases/kernel/containers/netns/netns_helper.sh b/testcases/kernel/containers/netns/netns_helper.sh  
> ...
> > +			tst_brkm TCONF "Command not supported (maybe missing 'veth' support)"  
> 
> ..
> > diff --git a/testcases/kernel/containers/netns/netns_sysfs.sh b/testcases/kernel/containers/netns/netns_sysfs.sh  
> ..
> > +		tst_brkm TCONF "Command not supported (maybe missing 'dummy' support)"  
> 
> Can you implement this patch with TST_NEEDS_DRIVERS (recently contributed by
> Alexey Kodanev)? Thanks a lot!

Yes, sure !

I will implement it but not in the next weeks because I am going to be
away until the end of November.

Best regards,
Petr Vorel Oct. 8, 2018, 10:15 a.m. UTC | #9 
Hi Mylène,

> > > diff --git a/testcases/kernel/containers/netns/netns_helper.sh b/testcases/kernel/containers/netns/netns_helper.sh  
> > ...
> > > +			tst_brkm TCONF "Command not supported (maybe missing 'veth' support)"  

> > ..
> > > diff --git a/testcases/kernel/containers/netns/netns_sysfs.sh b/testcases/kernel/containers/netns/netns_sysfs.sh  
> > ..
> > > +		tst_brkm TCONF "Command not supported (maybe missing 'dummy' support)"  

> > Can you implement this patch with TST_NEEDS_DRIVERS (recently contributed by
> > Alexey Kodanev)? Thanks a lot!

> Yes, sure !

> I will implement it but not in the next weeks because I am going to be
> away until the end of November.
Both are pretty simple one liner patches, but no problem, it can wait for you :).

Kind regards,
Petr
diff mbox series

Patch

diff --git a/testcases/kernel/containers/netns/netns_helper.sh b/testcases/kernel/containers/netns/netns_helper.sh
index 6aea10b47..58be60148 100755
--- a/testcases/kernel/containers/netns/netns_helper.sh
+++ b/testcases/kernel/containers/netns/netns_helper.sh
@@ -199,8 +199,14 @@  netns_ns_exec_setup()
 		tst_brkm TBROK "unable to create a new network namespace"
 	fi
 
-	$NS_EXEC $NS_HANDLE0 $NS_TYPE ip link add veth0 type veth peer name veth1 || \
+	local output=$($NS_EXEC $NS_HANDLE0 $NS_TYPE ip link add veth0 type \
+				veth peer name veth1 2>&1 || echo 'TERR')
+	if echo "$output" | grep -q "TERR"; then
+		echo "$output" | grep -q \
+			'RTNETLINK answers: Operation not supported' && \
+			tst_brkm TCONF "Command not supported (maybe missing 'veth' support)"
 		tst_brkm TBROK "unable to create veth pair devices"
+	fi
 
 	$NS_EXEC $NS_HANDLE0 $NS_TYPE ns_ifmove veth1 $NS_HANDLE1
 	ret=$?
@@ -235,8 +241,14 @@  netns_ip_setup()
 	ip netns add $NS_HANDLE1 || \
 		tst_brkm TBROK "unable to create a new network namespace"
 
-	$NS_EXEC $NS_HANDLE0 ip link add veth0 type veth peer name veth1 || \
+	local output=$($NS_EXEC $NS_HANDLE0 ip link add veth0 type \
+				veth peer name veth1 2>&1 || echo 'TERR')
+	if echo "$output" | grep -q "TERR"; then
+		echo "$output" | grep -q \
+			'RTNETLINK answers: Operation not supported' && \
+			tst_brkm TCONF "Command not supported (maybe missing 'veth' support)"
 		tst_brkm TBROK "unable to create veth pair devices"
+	fi
 
 	$NS_EXEC $NS_HANDLE0 ip link set veth1 netns $NS_HANDLE1 || \
 		tst_brkm TBROK "unable to add device veth1 to the separate network namespace"
diff --git a/testcases/kernel/containers/netns/netns_sysfs.sh b/testcases/kernel/containers/netns/netns_sysfs.sh
index 944a4c152..138d11402 100644
--- a/testcases/kernel/containers/netns/netns_sysfs.sh
+++ b/testcases/kernel/containers/netns/netns_sysfs.sh
@@ -54,8 +54,12 @@  if [ $? -eq 1 ]; then
 fi
 TST_CLEANUP=cleanup
 
-ip link add $DUMMYDEV_HOST type dummy || \
+output=$(ip link add $DUMMYDEV_HOST type dummy 2>&1 || echo 'TERR')
+if echo "$output" | grep -q "TERR"; then
+	echo "$output" | grep -q 'RTNETLINK answers: Operation not supported' && \
+		tst_brkm TCONF "Command not supported (maybe missing 'dummy' support)"
 	tst_brkm TBROK "failed to add a new (host) dummy device"
+fi
 
 ns_exec $NS_HANDLE $NS_TYPE mount --make-rprivate /sys
 ns_exec $NS_HANDLE $NS_TYPE ip link add $DUMMYDEV type dummy || \