linux-toradex.git/net/core/rtnetlink.c, branch v3.18.12

net: do not use rcu in rtnl_dump_ifinfo()

2015-03-14T19:37:13+00:00

[ Upstream commit cac5e65e8a7ea074f2626d2eaa53aa308452dec4 ]

We did a failed attempt in the past to only use rcu in rtnl dump
operations (commit e67f88dd12f6 "net: dont hold rtnl mutex during
netlink dump callbacks")

Now that dumps are holding RTNL anyway, there is no need to also
use rcu locking, as it forbids any scheduling ability, like
GFP_KERNEL allocations that controlling path should use instead
of GFP_ATOMIC whenever possible.

This should fix following splat Cong Wang reported :

 [ INFO: suspicious RCU usage. ]
 3.19.0+ #805 Tainted: G        W

 include/linux/rcupdate.h:538 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 2 locks held by ip/771:
  #0:  (rtnl_mutex){+.+.+.}, at: [] netlink_dump+0x21/0x26c
  #1:  (rcu_read_lock){......}, at: [] rcu_read_lock+0x0/0x6e

 stack backtrace:
 CPU: 3 PID: 771 Comm: ip Tainted: G        W       3.19.0+ #805
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  0000000000000001 ffff8800d51e7718 ffffffff81a27457 0000000029e729e6
  ffff8800d6108000 ffff8800d51e7748 ffffffff810b539b ffffffff820013dd
  00000000000001c8 0000000000000000 ffff8800d7448088 ffff8800d51e7758
 Call Trace:
  [] dump_stack+0x4c/0x65
  [] lockdep_rcu_suspicious+0x107/0x110
  [] rcu_preempt_sleep_check+0x45/0x47
  [] ___might_sleep+0x1d/0x1cb
  [] __might_sleep+0x78/0x80
  [] idr_alloc+0x45/0xd1
  [] ? rcu_read_lock_held+0x3b/0x3d
  [] ? idr_for_each+0x53/0x101
  [] alloc_netid+0x61/0x69
  [] __peernet2id+0x79/0x8d
  [] peernet2id+0x13/0x1f
  [] rtnl_fill_ifinfo+0xa8d/0xc20
  [] ? __lock_is_held+0x39/0x52
  [] rtnl_dump_ifinfo+0x149/0x213
  [] netlink_dump+0xef/0x26c
  [] netlink_recvmsg+0x17b/0x2c5
  [] __sock_recvmsg+0x4e/0x59
  [] sock_recvmsg+0x3f/0x51
  [] ___sys_recvmsg+0xf6/0x1d9
  [] ? handle_pte_fault+0x6e1/0xd3d
  [] ? native_sched_clock+0x35/0x37
  [] ? sched_clock_local+0x12/0x72
  [] ? sched_clock_cpu+0x9e/0xb7
  [] ? rcu_read_lock_held+0x3b/0x3d
  [] ? __fcheck_files+0x4c/0x58
  [] ? __fget_light+0x2d/0x52
  [] __sys_recvmsg+0x42/0x60
  [] SyS_recvmsg+0x12/0x1c

Signed-off-by: Eric Dumazet 
Fixes: 0c7aecd4bde4b7302 ("netns: add rtnl cmd to add and get peer netns ids")
Cc: Nicolas Dichtel 
Reported-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

rtnetlink: call ->dellink on failure when ->newlink exists

2015-03-14T19:37:10+00:00

[ Upstream commit 7afb8886a05be68e376655539a064ec672de8a8e ]

Ignacy reported that when eth0 is down and add a vlan device
on top of it like:

  ip link add link eth0 name eth0.1 up type vlan id 1

We will get a refcount leak:

  unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2

The problem is when rtnl_configure_link() fails in rtnl_newlink(),
we simply call unregister_device(), but for stacked device like vlan,
we almost do nothing when we unregister the upper device, more work
is done when we unregister the lower device, so call its ->dellink().

Reported-by: Ignacy Gawedzki 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY

2015-03-14T19:37:09+00:00

[ Upstream commit 364d5716a7adb91b731a35765d369602d68d2881 ]

ifla_vf_policy[] is wrong in advertising its individual member types as
NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
len member as *max* attribute length [0, len].

The issue is that when do_setvfinfo() is being called to set up a VF
through ndo handler, we could set corrupted data if the attribute length
is less than the size of the related structure itself.

The intent is exactly the opposite, namely to make sure to pass at least
data of minimum size of len.

Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
Cc: Mitch Williams 
Cc: Jeff Kirsher 
Signed-off-by: Daniel Borkmann 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify

2015-02-27T01:49:01+00:00

[ Upstream commit 59ccaaaa49b5b096cdc1f16706a9f931416b2332 ]

Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081

This patch avoids calling rtnl_notify if the device ndo_bridge_getlink
handler does not return any bytes in the skb.

Alternately, the skb->len check can be moved inside rtnl_notify.

For the bridge vlan case described in 92081, there is also a fix needed
in bridge driver to generate a proper notification. Will fix that in
subsequent patch.

v2: rebase patch on net tree

Signed-off-by: Roopa Prabhu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rtnetlink: release net refcnt on error in do_setlink()

2014-11-30T05:05:43+00:00

rtnl_link_get_net() holds a reference on the 'struct net', we need to release
it in case of error.

CC: Eric W. Biederman 
Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
Signed-off-by: Nicolas Dichtel 
Reviewed-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller

bridge: Sanitize IFLA_EXT_MASK for AF_BRIDGE:RTM_GETLINK

2014-11-26T20:29:01+00:00

Only search for IFLA_EXT_MASK if the message actually carries a
ifinfomsg header and validate minimal length requirements for
IFLA_EXT_MASK.

Fixes: 6cbdceeb ("bridge: Dump vlan information from a bridge port")
Cc: Vlad Yasevich 
Signed-off-by: Thomas Graf 
Signed-off-by: David S. Miller

bridge: Validate IFLA_BRIDGE_FLAGS attribute length

2014-11-26T20:29:00+00:00

Payload is currently accessed blindly and may exceed valid message
boundaries.

Fixes: 407af3299 ("bridge: Add netlink interface to configure vlans on bridge ports")
Cc: Vlad Yasevich 
Signed-off-by: Thomas Graf 
Signed-off-by: David S. Miller

rtnl/do_setlink(): notify when a netdev is modified

2014-09-02T19:57:04+00:00

Depending on which parameters were updated, the changes were not propagated via
the notifier chain and netlink.

The new flag has been set only when the change did not cause a call to the
notifier chain and/or to the netlink notification functions.

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

rtnl/do_setlink(): last arg is now a set of flags

2014-09-02T19:57:04+00:00

There is no functional changes with this commit, it only prepares the next one.

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

rtnl/do_setlink(): set modified when IFLA_LINKMODE is updated

2014-09-02T19:57:04+00:00

The only effect of this patch is to print a warning if IFLA_LINKMODE is updated
and a following change fails.

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller