On Sat, Aug 12, 2017 at 1:15 AM, Ben Pfaff wrote:
> I don't know. This patch seems to say that it fixes a problem if we
> revert commit 8c2c225e481d ("netdev: Fix netdev_open() to track and
> recreate classless interfaces"). That patch hasn't been reverted.
> Given that, can you explain the valu
I don't know. This patch seems to say that it fixes a problem if we
revert commit 8c2c225e481d ("netdev: Fix netdev_open() to track and
recreate classless interfaces"). That patch hasn't been reverted.
Given that, can you explain the value of this patch?
Is removing route_table_reset() related t
Hi Ben, this patch is ok ?
On Fri, Aug 4, 2017 at 10:45 AM, Tonghao Zhang wrote:
> We can avoid the deadlock via removing the route_table_reset() from
> the route_table_init()
>
> the call trace is below
> dp_initialize (ovsthread_once)
> route_table_init
> route_table_reset
>
We can avoid the deadlock via removing the route_table_reset() from
the route_table_init()
the call trace is below
dp_initialize (ovsthread_once)
route_table_init
route_table_reset
route_table_handle_msg
ovs_router_insert__
ovs_router_insert__
get
On Tue, Jul 18, 2017 at 08:44:15PM -0700, Tonghao Zhang wrote:
> ovs-router module uses the netdev_open() to get routes.
> But this module always calls the netdev_open() with type
> which is NULL. This module may open the eth0, vethx,
> vxlan_sys_4789, br0 if these network devices exist. And
> thes
ovs-router module uses the netdev_open() to get routes.
But this module always calls the netdev_open() with type
which is NULL. This module may open the eth0, vethx,
vxlan_sys_4789, br0 if these network devices exist. And
these device will be opened as 'system' type.
When debugging, somewhere netd
