[ovs-dev] ovs-ctl: Don't remember vport-* kernel modules
diff mbox series

Message ID 1510353905-1442-1-git-send-email-guru@ovn.org
State Accepted
Headers show
Series
  • [ovs-dev] ovs-ctl: Don't remember vport-* kernel modules
Related show

Commit Message

Guru Shetty Nov. 10, 2017, 10:45 p.m. UTC
From OVS 2.8, ovs-vswitchd, when it starts, will
load the kernel modules for tunnels. It has logic
inside it to choose either upstream kernel module
or vport-* kernel module.

So, when we run 'force-reload-kmod' to upgrade to
OVS 2.8 from a previous version,  we do not need to
remember the vport-* kernel module that was previously
loaded.  It is not really harmful to load vport-* kernel
module though.

On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel
module for tunnels.

But, on RHEL 7.x we have hit a bug caused by iptables
startup script which tries to remove all kernel modules
related to linux conntrack. It fails to unload openvswitch
kernel module because it has a reference count on it. But it
succeeds in unloading vport-geneve and in turn the upstream
"geneve" kernel module.  This causes the tunnels to go down.

With this patch, we avoid the above situation, by not loading
vport-geneve kernel module.  ovs-vswitchd when it starts will
load upstream geneve. And when "iptables stop" runs, since
"geneve" has nothing to do with conntrack, it spares it.
Ideally, we should fix this by incrementing the refcount
on the kernel modules.

Signed-off-by: Gurucharan Shetty <guru@ovn.org>
---
 utilities/ovs-ctl.in | 11 -----------
 1 file changed, 11 deletions(-)

Comments

William Tu Nov. 13, 2017, 2:43 p.m. UTC | #1
On Fri, Nov 10, 2017 at 2:45 PM, Gurucharan Shetty <guru@ovn.org> wrote:
> From OVS 2.8, ovs-vswitchd, when it starts, will
> load the kernel modules for tunnels. It has logic
> inside it to choose either upstream kernel module
> or vport-* kernel module.
>
> So, when we run 'force-reload-kmod' to upgrade to
> OVS 2.8 from a previous version,  we do not need to
> remember the vport-* kernel module that was previously
> loaded.  It is not really harmful to load vport-* kernel
> module though.
>
> On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel
> module for tunnels.
>
> But, on RHEL 7.x we have hit a bug caused by iptables
> startup script which tries to remove all kernel modules
> related to linux conntrack. It fails to unload openvswitch
> kernel module because it has a reference count on it. But it
> succeeds in unloading vport-geneve and in turn the upstream
> "geneve" kernel module.  This causes the tunnels to go down.
>
> With this patch, we avoid the above situation, by not loading
> vport-geneve kernel module.  ovs-vswitchd when it starts will
> load upstream geneve. And when "iptables stop" runs, since
> "geneve" has nothing to do with conntrack, it spares it.
> Ideally, we should fix this by incrementing the refcount
> on the kernel modules.
>
> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
> ---
Looks good to me.

Acked-by: William Tu <u9012063@gmail.com>
Guru Shetty Nov. 13, 2017, 4:35 p.m. UTC | #2
On 13 November 2017 at 06:43, William Tu <u9012063@gmail.com> wrote:

> On Fri, Nov 10, 2017 at 2:45 PM, Gurucharan Shetty <guru@ovn.org> wrote:
> > From OVS 2.8, ovs-vswitchd, when it starts, will
> > load the kernel modules for tunnels. It has logic
> > inside it to choose either upstream kernel module
> > or vport-* kernel module.
> >
> > So, when we run 'force-reload-kmod' to upgrade to
> > OVS 2.8 from a previous version,  we do not need to
> > remember the vport-* kernel module that was previously
> > loaded.  It is not really harmful to load vport-* kernel
> > module though.
> >
> > On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel
> > module for tunnels.
> >
> > But, on RHEL 7.x we have hit a bug caused by iptables
> > startup script which tries to remove all kernel modules
> > related to linux conntrack. It fails to unload openvswitch
> > kernel module because it has a reference count on it. But it
> > succeeds in unloading vport-geneve and in turn the upstream
> > "geneve" kernel module.  This causes the tunnels to go down.
> >
> > With this patch, we avoid the above situation, by not loading
> > vport-geneve kernel module.  ovs-vswitchd when it starts will
> > load upstream geneve. And when "iptables stop" runs, since
> > "geneve" has nothing to do with conntrack, it spares it.
> > Ideally, we should fix this by incrementing the refcount
> > on the kernel modules.
> >
> > Signed-off-by: Gurucharan Shetty <guru@ovn.org>
> > ---
> Looks good to me.
>
> Acked-by: William Tu <u9012063@gmail.com>
>
Thanks William. I applied this to master and 2.8
Eric Garver Nov. 27, 2017, 3:17 p.m. UTC | #3
On Fri, Nov 10, 2017 at 02:45:05PM -0800, Gurucharan Shetty wrote:
> From OVS 2.8, ovs-vswitchd, when it starts, will
> load the kernel modules for tunnels. It has logic
> inside it to choose either upstream kernel module
> or vport-* kernel module.
> 
> So, when we run 'force-reload-kmod' to upgrade to
> OVS 2.8 from a previous version,  we do not need to
> remember the vport-* kernel module that was previously
> loaded.  It is not really harmful to load vport-* kernel
> module though.
> 
> On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel
> module for tunnels.
> 
> But, on RHEL 7.x we have hit a bug caused by iptables
> startup script which tries to remove all kernel modules
> related to linux conntrack. It fails to unload openvswitch
> kernel module because it has a reference count on it. But it
> succeeds in unloading vport-geneve and in turn the upstream
> "geneve" kernel module.  This causes the tunnels to go down.
> 
> With this patch, we avoid the above situation, by not loading
> vport-geneve kernel module.  ovs-vswitchd when it starts will
> load upstream geneve. And when "iptables stop" runs, since
> "geneve" has nothing to do with conntrack, it spares it.
> Ideally, we should fix this by incrementing the refcount
> on the kernel modules.
> 
> Signed-off-by: Gurucharan Shetty <guru@ovn.org>

Hi Guru,
Sorry for the delayed response. I missed this before I went on holiday.

> ---
>  utilities/ovs-ctl.in | 11 -----------
>  1 file changed, 11 deletions(-)
> 
> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
> index 2e1209a..f1b01d1 100755
> --- a/utilities/ovs-ctl.in
> +++ b/utilities/ovs-ctl.in
> @@ -30,17 +30,9 @@ done
>  ## start ##
>  ## ----- ##
>  
> -# Keep track of removed vports so we can reload them if needed
> -removed_vports=""
> -
>  insert_mods () {
>      # Try loading openvswitch again.
>      action "Inserting openvswitch module" modprobe openvswitch
> -
> -    for vport in $removed_vports; do
> -        # Don't treat failures to load vports as fatal error
> -        action "Inserting $vport module" modprobe $vport || true
> -    done
>  }

Does this break things if we can't use the in kernel tunnels? Have you
tried this on an < 4.3 kernel? In that case we should have to use the
compat/vport interface.

>  
>  insert_mod_if_required () {
> @@ -398,9 +390,6 @@ force_reload_kmod () {
>  
>      for vport in `awk '/^vport_/ { print $1 }' /proc/modules`; do
>          action "Removing $vport module" rmmod $vport
> -        if ! grep -q $vport /proc/modules; then
> -            removed_vports="$removed_vports $vport"
> -        fi
>      done
>  
>      if test -e /sys/module/openvswitch; then
> -- 
> 2.7.4
> 
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Patch
diff mbox series

diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index 2e1209a..f1b01d1 100755
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -30,17 +30,9 @@  done
 ## start ##
 ## ----- ##
 
-# Keep track of removed vports so we can reload them if needed
-removed_vports=""
-
 insert_mods () {
     # Try loading openvswitch again.
     action "Inserting openvswitch module" modprobe openvswitch
-
-    for vport in $removed_vports; do
-        # Don't treat failures to load vports as fatal error
-        action "Inserting $vport module" modprobe $vport || true
-    done
 }
 
 insert_mod_if_required () {
@@ -398,9 +390,6 @@  force_reload_kmod () {
 
     for vport in `awk '/^vport_/ { print $1 }' /proc/modules`; do
         action "Removing $vport module" rmmod $vport
-        if ! grep -q $vport /proc/modules; then
-            removed_vports="$removed_vports $vport"
-        fi
     done
 
     if test -e /sys/module/openvswitch; then