[ovs-dev] [PATCH] datapath: Enforce matching of kernel releases on loading openvswitch.ko

Aaron Conole aconole at redhat.com
Wed Dec 13 22:00:43 UTC 2017


Yifeng Sun <pkusunyifeng at gmail.com> writes:

> Thanks for your review.
>
> Since CONFIG_MODVERSIONS is default to 'y' in most cases, I'd say this
> is to circumvent CONFIG_MODVERSIONS=y.
>
> This happened when redhat kernel was upgraded from
> 3.10.0-514.el7.x86_64 to 3.10.0-693.1.1.el7.x86_64. When 693 uses the
> openvswitch.ko built for 514, some error happened.

Maybe you want something like a dkms module?  I'm not sure.  I do know
that RHEL ships an openvswitch.ko which is kept up to date with
upstream, and should have been shipped with the kernel.  Is that not the
case?

> On Wed, Dec 13, 2017 at 10:24 AM, Aaron Conole <aconole at redhat.com> wrote:
>
>  Yifeng Sun <pkusunyifeng at gmail.com> writes:
>
>  > 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 <pkusunyifeng at gmail.com>
>  > ---
>
>  Is this to circumvent CONFIG_MODVERSIONS=n?
>
>  This seems like a situation that shouldn't happen.  When upgrading, the
>  installed version (make modules_install) should be matched (ie: a
>  modprobe won't work because the kernel `uname -r` directory changed).
>  Otherwise, a new build should be done by the developer that changed out
>  their kernel (because they are manually building OvS modules and
>  installing from the source tree).
>
>  I'm probably not understanding the use case.


More information about the dev mailing list