[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