[Bionic/Cosmic/Disco/Unstable][SRU][PATCH 1/1] UBUNTU: SAUCE: openvswitch: Disable eventmask support on 32-bit
andrea.righi at canonical.com
Fri Apr 5 07:07:42 UTC 2019
On Fri, Apr 05, 2019 at 08:10:42AM +0200, Juerg Haefliger wrote:
> On Mon, 11 Mar 2019 08:53:22 -0300
> Thadeu Lima de Souza Cascardo <cascardo at canonical.com> wrote:
> > On Mon, Mar 11, 2019 at 08:36:43AM +0100, Juerg Haefliger wrote:
> > > BugLink: https://bugs.launchpad.net/bugs/1736390
> > >
> > > Openvswitch eventmask support for CT actions was introduced with commit
> > > 120645513f55 ("openvswitch: Add eventmask support to CT action."). This
> > > commit introduces a regression on i386 which results in a kernel crash.
> > > Fix that by disabling eventmask support on i386.
> > >
> > > Per upstream, the result of *not* having this "will cause additional CPU
> > > use and potential buffering issues for CT event monitors in userspace."
> > >
> > > https://lore.kernel.org/lkml/E891AED6-8406-4914-BDC3-92248F77C63B@ovn.org/
> > >
> > > Fixes: 120645513f55 ("openvswitch: Add eventmask support to CT action.")
> > > Signed-off-by: Juerg Haefliger <juergh at canonical.com>
> > > ---
> > > include/uapi/linux/openvswitch.h | 2 ++
> > > net/openvswitch/conntrack.c | 12 ++++++++++++
> > > 2 files changed, 14 insertions(+)
> > >
> > I have gone through the bug, the ovs thread and the ovs patch, with some of the
> > explanation from Jarno on why this should only be disabled on i386.
> > I am still not very comfortable with this, as this seems to be corrupting
> > memory on different places, by looking at the backtrace you used on the ovs-dev
> > mailing list.
> Yes. That's why I want to disable it completely on i386 until upstream comes
> up with a root-cause/fix (which they haven't so far).
> > In any case, I failed to identify the test results with the patch applied on
> > the bug. Can you tell more about them?
> The simple case is to just add and delete an OVS bridge repeatedly which kills
> the (i386) machine without this patch.
This bug might be a duplicate of LP: #1813244.
I've tried to reproduce the problem creating and deleting a bridge in a
busy loop and with LP: #1813244's fix applied the bug doesn't seem to
More information about the kernel-team