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 |
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 || \ >
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.
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
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. >
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.
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.
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
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,
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 --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 || \
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(-)