And one more thing I forgot to say. With latest distributions (e.g RHEL7.x
or Ubuntu 16.04), they already come with a openvswitch kernel module (from
upstream linux). And that kernel module gets placed in /lib/modules/'uname
-r`/kernel/net/openvswitch. But that kernel module is tied to the features
that we added for that kernel. And they usually are 2 years old. So, we
build our own kernel module packages with the latest and greatest features.
The important thing for us is that when we install the kernel module
package from this repo:
1. 'modinfo openvswitch' should show our kernel module package.
2. We should run: "/etc/init.d/openvswitch force-reload-kmod" to remove
the kernel module that came from upstream linux and add our kernel module.
What we are seeing these days is that either of the above 2 goes wrong and
we end up using a older kernel module.
On 13 December 2017 at 14:24, Guru Shetty <g...@ovn.org> wrote:
>
>
> On 12 December 2017 at 07:59, Yifeng Sun <pkusunyif...@gmail.com> wrote:
>
>> Deployment and upgrade failure is quite often caused by that
>> openvswitch.ko was
>> built upon kernel x.y.z-release-A while it is loaded into a running kernel
>> of x.y.z-release-B. This patch proposes to enforce the matching of the two
>> kernel release numbers at the moment of deployment and upgrading.
>>
>> Signed-off-by: Yifeng Sun <pkusunyif...@gmail.com>
>>
>
> Yifeng,
> The issue in question is a little different. What usually happens is that
> we build OVS $version (e.g OVS 2.8.0) kernel module for a particular redhat
> release (say RHEL 7.4). But, RHEL7.4 updates its minor version (for e.g a
> security update). Unless, there is a ABI change in that changed minor
> version, we should still be able to use the package that we already built
> for the previous minor version. With RHEL 6.x, this was usually not a
> problem as the openvswitch.ko that we build would land in weak-updates
> directory of redhat kernel of the newer minor version.
>
> But something has changed with RHEL7.x, where the package that we install
> does not land in "weak-updates"., but instead lands in a separate kernel
> (the one that we built it for)
> The potential solution for it after running some tests looks to be for us
> to change the name of /etc/depmod.d/openvswitch.conf to
> /etc/depmod.d/01openvswitch.conf and then add a line at the top:
>
> search extra/openvswitch weak-updates/openvswitch updates extra built-in
> weak-updates
>
> Most likely, with RHEL7.x, there is a new file called
> /etc/depmod.d/dist.conf which searches for "search updates extra built-in
> weak-updates". So, when the kernel module package from this repo is
> installed, it does not land it in "weak-updates" of the running kernel.
>
>
>
>
>> ---
>> datapath/datapath.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/datapath/datapath.c b/datapath/datapath.c
>> index 178081993b42..0e3a1db63847 100644
>> --- a/datapath/datapath.c
>> +++ b/datapath/datapath.c
>> @@ -51,6 +51,8 @@
>> #include <net/genetlink.h>
>> #include <net/net_namespace.h>
>> #include <net/netns/generic.h>
>> +#include <generated/utsrelease.h>
>> +#include <linux/utsname.h>
>>
>> #include "datapath.h"
>> #include "conntrack.h"
>> @@ -61,6 +63,8 @@
>> #include "vport-internal_dev.h"
>> #include "vport-netdev.h"
>>
>> +static const char *build_kernel_release = UTS_RELEASE;
>> +
>> unsigned int ovs_net_id __read_mostly;
>>
>> static struct genl_family dp_packet_genl_family;
>> @@ -2406,6 +2410,15 @@ static int __init dp_init(void)
>>
>> BUILD_BUG_ON(sizeof(struct ovs_skb_cb) > FIELD_SIZEOF(struct
>> sk_buff, cb));
>>
>> + if (strcmp(build_kernel_release, utsname()->release)) {
>> + pr_err("Failed to load Open vSwitch kernel module: "
>> + "the modules' built-on kernel release
>> (%s) "
>> + "doesn't match the running kernel's
>> release (%s)\n",
>> + build_kernel_release, utsname()->release);
>> + err = -EINVAL;
>> + goto error;
>> + }
>> +
>> pr_info("Open vSwitch switching datapath %s\n", VERSION);
>>
>> err = action_fifos_init();
>> --
>> 2.7.4
>>
>>
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
