From: Jiri Jaburek <jjaburek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] containers/netns/netns_sysfs.sh:load dummy module before collecting sysfs interface
Date: Fri, 6 Nov 2015 18:16:23 +0100 [thread overview]
Message-ID: <563CE067.90803@redhat.com> (raw)
In-Reply-To: <1446195470-7568-1-git-send-email-shuang.qiu@oracle.com>
On 10/30/2015 09:57 AM, shuang.qiu@oracle.com wrote:
> From: Shuang Qiu <shuang.qiu@oracle.com>
>
> If dummy is compiled as module in kernel,it is loaded dynamically when
> adding dummy device.And it will also create a default dummy interface.So
> the sysfs_after will have one more interface than sysfs_before which
> makes testcase #3 failed.Loading dummy module before collecting sysfs
> interface to workaround such issue.
I cannot reproduce this on any RHEL or Fedora system, but I can
reproduce it on Debian (Jessie). If we accounted only for the module
version of 'dummy', it could be countered by adding
options dummy numdummies=0
to any /etc/modprobe.d/* config (temporarily), however for the built-in
version of the module, such option would need to be passed via kernel
cmdline.
We could check [ -d /sys/module/dummy ] and if it exists, presume that
no extra setup is necessary, because
1) if it's a module, our creation of additional dummy interface won't
affect existing interfaces as dummy0 is created only on insmod
(dummy_init_one() is called during __init with numdummies=1)
2) if it's built in, well .. see (1)
otherwise we can try modprobing it and if it fails, end with CONF.
However - wouldn't it be simply easier to add an exception for dummy0
during the comparison check? The test operates with iface names other
than dummy0, so a possible namespace bug would be found anyway.
(See attached diff.)
However the (quite possibly) best solution would be a one which cleans
up after itself, so maybe the [ -d /sys/module/dummy ] solution with
explicit modprobe / modprobe -r would work better.
Your choice. :)
Jiri
> Signed-off-by: Shuang Qiu <shuang.qiu@oracle.com>
> ---
> testcases/kernel/containers/netns/netns_sysfs.sh | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/testcases/kernel/containers/netns/netns_sysfs.sh b/testcases/kernel/containers/netns/netns_sysfs.sh
> index 7dea52b..b5791bd 100755
> --- a/testcases/kernel/containers/netns/netns_sysfs.sh
> +++ b/testcases/kernel/containers/netns/netns_sysfs.sh
> @@ -47,6 +47,10 @@ if [ $? -eq 1 ]; then
> tst_brkm TBROK "unable to create a new network namespace"
> fi
> TST_CLEANUP=cleanup
> +
> +#Load dummy module before collecting sysfs interface
> +lsmod | grep dummy || modprobe dummy
> +[ $? -eq 0 ] || tst_brkm TBROK "failed to load dummy module"
> ls /sys/class/net >sysfs_before
>
> ns_exec $NS_HANDLE $NS_TYPE mount --make-rprivate /sys
>
-------------- next part --------------
diff --git a/testcases/kernel/containers/netns/netns_sysfs.sh b/testcases/kernel/containers/netns/netns_sysfs.sh
index 7dea52b..e725a50 100755
--- a/testcases/kernel/containers/netns/netns_sysfs.sh
+++ b/testcases/kernel/containers/netns/netns_sysfs.sh
@@ -47,7 +47,10 @@ if [ $? -eq 1 ]; then
tst_brkm TBROK "unable to create a new network namespace"
fi
TST_CLEANUP=cleanup
-ls /sys/class/net >sysfs_before
+
+# exclude dummy0 from comparison as it gets automatically created by the
+# dummy device driver upon insmod/modprobe (during ip link add)
+ls /sys/class/net | grep -v dummy0 >sysfs_before
ns_exec $NS_HANDLE $NS_TYPE mount --make-rprivate /sys
ns_exec $NS_HANDLE $NS_TYPE ip link add $DUMMYDEV type dummy || \
@@ -84,7 +87,7 @@ fi
# TEST CASE #3
-ls /sys/class/net >sysfs_after
+ls /sys/class/net | grep -v dummy0 >sysfs_after
diff sysfs_before sysfs_after
if [ $? -eq 0 ]; then
tst_resm TPASS "sysfs not affected by a separate namespace"
next prev parent reply other threads:[~2015-11-06 17:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 8:57 [LTP] [PATCH] containers/netns/netns_sysfs.sh:load dummy module before collecting sysfs interface shuang.qiu
2015-11-04 12:49 ` Cyril Hrubis
2015-11-05 4:46 ` Shuang Qiu
2015-11-05 14:05 ` Cyril Hrubis
2015-11-06 10:28 ` Shuang Qiu
2015-11-06 17:16 ` Jiri Jaburek [this message]
2015-11-09 14:14 ` Cyril Hrubis
2015-11-09 15:20 ` Jiri Jaburek
2015-11-09 15:26 ` Cyril Hrubis
2015-11-10 4:03 ` Shuang Qiu
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=563CE067.90803@redhat.com \
--to=jjaburek@redhat.com \
--cc=ltp@lists.linux.it \
/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 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.