Hi list,

I have viewed OVS git logs and found that register rtnl_link_ops is
introduced by commit 5282e284ac575f52c19c89b1ffc392a181b3fa2b (datapath:
introduce rtnl ops stub) , the purpose is for help user space tool like ip
link to view IFLA_INFO_KIND property.

Regard kernel < 3.17 does not strictly block the destroy call trigger by
using ip link, I think we'd better detect kernel version and register
rtnl_link_ops only when kernel version is good for doing that.

In our scenario we do not use IFA_INFO_KIND property, however I may miss
some point, If we can skip register the ops, I wil send a patch to disable
under kernel < 3.17.

Thanks a lot.

2016-11-24 17:37 GMT+08:00 张东亚 <fortitude.zh...@gmail.com>:

> Hi,
>
> Ovs 2.5.0+ have registered internal_dev_link_ops to kernel, and also set
> rtnl_link_ops field of net_device.
>
> However, under kernel version < 3.17, due to commit
> b0ab2fabb5b91da99c189db02e91ae10bc8355c5
> <https://github.com/torvalds/linux/commit/b0ab2fabb5b91da99c189db02e91ae10bc8355c5>
>  of
> kernel is not merged, user can delete the internal device by using ip link
> del directly, this will free the vport in kernel directly without detach it
> from
> dp and vport hash, this will make later dp-ctl access the freed memory of
> the vport, cause variuous problems.
>
> My questions is why ovs try to register rtnl_link_ops? can we disable the
> registration under kernel version < 3.17?
>
> Thanks a lot.
>
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to