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

Yifeng Sun pkusunyifeng at gmail.com
Wed Dec 13 22:21:57 UTC 2017


Thanks for introducing dkms to me, I didn't know about it. If I am not
wrong, it
seems dkms can rebuild the openvswitch module against the new kernel
release.
That may solve the issue, but one concern is that the openvswitch.ko is not
tested on the new release.

When RHEL comes out with a new kernel release, its kernel version may not
change, like the case that I mentioned in the previous email. In this case,
openvswitch.ko is up to date with the kernel version but may not work with
the new release.


On Wed, Dec 13, 2017 at 2:00 PM, Aaron Conole <aconole at redhat.com> wrote:

> 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