On Thu, Apr 27, 2017 at 11:17 AM, Ben Pfaff <b...@ovn.org> wrote: > On Thu, Apr 27, 2017 at 10:17:20AM -0700, William Tu wrote: >> On Thu, Apr 27, 2017 at 9:57 AM, Ben Pfaff <b...@ovn.org> wrote: >> > On Thu, Apr 27, 2017 at 04:02:10AM -0700, William Tu wrote: >> >> Before the patch, when users create bridge named "default", although >> >> ovs-vsctl fails but vswitchd in the background will keep retrying it, >> >> causing the systemd-udev to reach 100% cpu utilization. The reason is >> >> due to frequent calls into kernel's register_netdevice function, >> >> which will invoke several kernel elements who has registered on the >> >> netdevice notifier chain. One of the notifier, the inetdev_event rejects >> >> this devname and register_netdevice fails. The patch prohibits creating >> >> "default" bridge name. >> >> >> >> VMWare-BZ: #1842388 >> >> Signed-off-by: William Tu <u9012...@gmail.com> >> > >> > It all seems very arbitrary. Do we understand why this is an invalid >> > device name? >> >> Yes, when kernel is configured with CONFIG_SYSCTL, creating a new >> netdev creates a dir in /proc/sys/net/ipv4/conf/<device name> >> >> The <device name> "default" and "all" is pre-existed when SYSCTL >> starts (which means we should also prohibit "all") for default >> property of the system's netdev. So sysctl prevents creating dev->name >> is "default" or "all". A call stack is below if interested: >> sysctl_dev_name_is_allowed >> devinet_sysctl_register >> inetdev_event >> notifier_call_chain >> raw_notifier_call_chain >> call_netdevice_notifiers_info >> register_netdevice > > Do we get the same behavior (100% CPU) if creating a bridge fails for > other reasons? For example, it might fail because a network device > already exists with the given name, or because the name is too long for > a network device name. If we do get 100% CPU from such a failure, then > we should fix the root of the problem instead of blacklisting particular > names.
There are two scenarios: 1) if the bridge name exists, ex: eth0 then "ovs-vsctl add-br eth0" fails due to EEXIST 2) if the bridge name does not exists, but is "default" or "all" then "ovs-vsctl add-br default" fails due to EINVAL >From OVS's point of view it's the same, ovs-vsctl fails creating the bridge, and keeps retry. From the whole system's point of view, (2) has impact on other Linux subsystems, due to kernel netdev notifier chain mechanism informing other subsystems when trying to add a new device, while (1) fails pretty early in register_netdevice() and has no impact. Or instead of blacklisting, maybe add a max retry count? Regards, William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
