lwn.git/net/core/rtnetlink.c, branch v3.14.5

rtnetlink: wait for unregistering devices in rtnl_link_unregister()

2014-05-31T20:20:38+00:00

[ Upstream commit 200b916f3575bdf11609cb447661b8d5957b0bbf ] From: Cong Wang commit 50624c934db18ab90 (net: Delay default_device_exit_batch until no devices are unregistering) introduced rtnl_lock_unregistering() for default_device_exit_batch(). Same race could happen we when rmmod a driver which calls rtnl_link_unregister() as we call dev->destructor without rtnl lock. For long term, I think we should clean up the mess of netdev_run_todo() and net namespce exit code. Cc: Eric W. Biederman Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

rtnetlink: Only supply IFLA_VF_PORTS information when RTEXT_FILTER_VF is set

2014-05-31T20:20:35+00:00

[ Upstream commit c53864fd60227de025cb79e05493b13f69843971 ] Since 115c9b81928360d769a76c632bae62d15206a94a (rtnetlink: Fix problem with buffer allocation), RTM_NEWLINK messages only contain the IFLA_VFINFO_LIST attribute if they were solicited by a GETLINK message containing an IFLA_EXT_MASK attribute with the RTEXT_FILTER_VF flag. That was done because some user programs broke when they received more data than expected - because IFLA_VFINFO_LIST contains information for each VF it can become large if there are many VFs. However, the IFLA_VF_PORTS attribute, supplied for devices which implement ndo_get_vf_port (currently the 'enic' driver only), has the same problem. It supplies per-VF information and can therefore become large, but it is not currently conditional on the IFLA_EXT_MASK value. Worse, it interacts badly with the existing EXT_MASK handling. When IFLA_EXT_MASK is not supplied, the buffer for netlink replies is fixed at NLMSG_GOODSIZE. If the information for IFLA_VF_PORTS exceeds this, then rtnl_fill_ifinfo() returns -EMSGSIZE on the first message in a packet. netlink_dump() will misinterpret this as having finished the listing and omit data for this interface and all subsequent ones. That can cause getifaddrs(3) to enter an infinite loop. This patch addresses the problem by only supplying IFLA_VF_PORTS when IFLA_EXT_MASK is supplied with the RTEXT_FILTER_VF flag set. Signed-off-by: David Gibson Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

rtnetlink: Warn when interface's information won't fit in our packet

2014-05-31T20:20:34+00:00

[ Upstream commit 973462bbde79bb827824c73b59027a0aed5c9ca6 ] Without IFLA_EXT_MASK specified, the information reported for a single interface in response to RTM_GETLINK is expected to fit within a netlink packet of NLMSG_GOODSIZE. If it doesn't, however, things will go badly wrong, When listing all interfaces, netlink_dump() will incorrectly treat -EMSGSIZE on the first message in a packet as the end of the listing and omit information for that interface and all subsequent ones. This can cause getifaddrs(3) to enter an infinite loop. This patch won't fix the problem, but it will WARN_ON() making it easier to track down what's going wrong. Signed-off-by: David Gibson Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

rtnetlink: fix fdb notification flags

2014-03-20T20:24:28+00:00

Commit 3ff661c38c84 ("net: rtnetlink notify events for FDB NTF_SELF adds and deletes") reuses the function nlmsg_populate_fdb_fill() to notify fdb events. But this function was used only for dump and thus was always setting the flag NLM_F_MULTI, which is wrong in case of a single notification. Libraries like libnl will wait forever for NLMSG_DONE. CC: Thomas Graf Signed-off-by: Nicolas Dichtel Acked-by: Thomas Graf Signed-off-by: David S. Miller

net: correct error path in rtnl_newlink()

2014-02-13T22:08:29+00:00

I saw the following BUG when ->newlink() fails in rtnl_newlink(): [ 40.240058] kernel BUG at net/core/dev.c:6438! this is due to free_netdev() is not supposed to be called before netdev is completely unregistered, therefore it is not correct to call free_netdev() here, at least for ops->newlink!=NULL case, many drivers call it in ->destructor so that rtnl_unlock() will take care of it, we probably don't need to do anything here. Cc: David S. Miller Cc: Eric Dumazet Signed-off-by: Cong Wang Signed-off-by: Cong Wang Signed-off-by: David S. Miller

rtnetlink: fix oops in rtnl_link_get_slave_info_data_size

2014-02-05T04:28:51+00:00

We should check whether rtnetlink link operations are defined before calling get_slave_size(). Without this, the following oops can occur when adding a tap device to OVS. [ 87.839553] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 [ 87.839595] IP: [] if_nlmsg_size+0xf0/0x220 [...] [ 87.840651] Call Trace: [ 87.840664] [] ? rtmsg_ifinfo+0x2b/0x100 [ 87.840688] [] ? __netdev_adjacent_dev_insert+0x150/0x1a0 [ 87.840718] [] ? rtnetlink_event+0x30/0x40 [ 87.840742] [] ? notifier_call_chain+0x44/0x70 [ 87.840768] [] ? __netdev_upper_dev_link+0x3c6/0x3f0 [ 87.840798] [] ? netdev_create+0xcc/0x160 [openvswitch] [ 87.840828] [] ? ovs_vport_add+0x4a/0xd0 [openvswitch] [ 87.840857] [] ? new_vport+0x9/0x50 [openvswitch] [ 87.840884] [] ? ovs_vport_cmd_new+0x11e/0x210 [openvswitch] [ 87.840915] [] ? genl_family_rcv_msg+0x19a/0x360 [ 87.840941] [] ? genl_family_rcv_msg+0x360/0x360 [ 87.840967] [] ? genl_rcv_msg+0x79/0xc0 [ 87.840991] [] ? __kmalloc_reserve.isra.25+0x29/0x80 [ 87.841018] [] ? netlink_rcv_skb+0xa9/0xc0 [ 87.841042] [] ? genl_rcv+0x1f/0x30 [ 87.841064] [] ? netlink_unicast+0xe8/0x1e0 [ 87.841088] [] ? netlink_sendmsg+0x31a/0x750 [ 87.841113] [] ? sock_sendmsg+0x86/0xc0 [ 87.841136] [] ? __netdev_update_features+0x4d/0x200 [ 87.841163] [] ? ethtool_get_value+0x2e/0x50 [ 87.841188] [] ? ___sys_sendmsg+0x359/0x370 [ 87.841212] [] ? dev_ioctl+0x1a6/0x5c0 [ 87.841236] [] ? autoremove_wake_function+0x30/0x30 [ 87.841264] [] ? sock_do_ioctl+0x3d/0x50 [ 87.841288] [] ? sock_ioctl+0x1e8/0x2c0 [ 87.841312] [] ? do_vfs_ioctl+0x2cf/0x4b0 [ 87.841335] [] ? __sys_sendmsg+0x39/0x70 [ 87.841362] [] ? system_call_fastpath+0x16/0x1b [ 87.841386] Code: c0 74 10 48 89 ef ff d0 83 c0 07 83 e0 fc 48 98 49 01 c7 48 89 ef e8 d0 d6 fe ff 48 85 c0 0f 84 df 00 00 00 48 8b 90 08 07 00 00 <48> 8b 8a a8 00 00 00 31 d2 48 85 c9 74 0c 48 89 ee 48 89 c7 ff [ 87.841529] RIP [] if_nlmsg_size+0xf0/0x220 [ 87.841555] RSP [ 87.841569] CR2: 00000000000000a8 [ 87.851442] ---[ end trace e42ab217691b4fc2 ]--- Signed-off-by: Fernando Luis Vazquez Cao Acked-by: Jiri Pirko Signed-off-by: David S. Miller

rtnetlink: remove check for fill_slave_info in rtnl_have_link_slave_info

2014-01-24T00:21:48+00:00

This check is not needed because the same check is done before fill_slave_info is used in rtnl_link_slave_info_fill. Also, by removing this check, kernel will fillup IFLA_INFO_SLAVE_KIND even for slaves of masters which does not implement fill_slave_info. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

bonding: convert netlink to use slave data info api

2014-01-23T05:57:17+00:00

Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

rtnetlink: provide api for getting and setting slave info

2014-01-23T05:57:05+00:00

Recent patch bonding: add netlink attributes to slave link dev (1d3ee88ae0d6) Introduced yet another device specific way to access slave information over rtnetlink. There is one already there for bridge. This patch introduces generic way to do this, for getting and setting info as well by extending link_ops. Later on, this new interface will be used for bridge ports as well. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

rtnetlink: put "BOND" into nl attribute names which are related to bonding

2014-01-23T05:57:05+00:00

Signed-off-by: Jiri Pirko Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller