linux-stable.git/net/core, branch v3.18.10

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

net: pktgen: disable xmit_clone on virtual devices

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

[ Upstream commit 52d6c8c6ca125872459054daa70f2f1c698c8e75 ]

Trying to use burst capability (aka xmit_more) on a virtual device
like bonding is not supported.

For example, skb might be queued multiple times on a qdisc, with
various list corruptions.

Fixes: 38b2cf2982dc ("net: pktgen: packet bursting via skb->xmit_more")
Signed-off-by: Eric Dumazet 
Cc: Alexei Starovoitov 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: reject creation of netdev names with colons

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

[ Upstream commit a4176a9391868bfa87705bcd2e3b49e9b9dd2996 ]

colons are used as a separator in netdev device lookup in dev_ioctl.c

Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

Signed-off-by: Matthew Thode 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

sock: sock_dequeue_err_skb() needs hard irq safety

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

[ Upstream commit 997d5c3f4427f38562cbe207ce05bb25fdcb993b ]

Non NAPI drivers can call skb_tstamp_tx() and then sock_queue_err_skb()
from hard IRQ context.

Therefore, sock_dequeue_err_skb() needs to block hard irq or
corruptions or hangs can happen.

Signed-off-by: Eric Dumazet 
Fixes: 364a9e93243d1 ("sock: deduplicate errqueue dequeue")
Fixes: cb820f8e4b7f7 ("net: Provide a generic socket error queue delivery method for Tx time stamps.")
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

gen_stats.c: Duplicate xstats buffer for later use

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

[ Upstream commit 1c4cff0cf55011792125b6041bc4e9713e46240f ]

The gnet_stats_copy_app() function gets called, more often than not, with its
second argument a pointer to an automatic variable in the caller's stack.
Therefore, to avoid copying garbage afterwards when calling
gnet_stats_finish_copy(), this data is better copied to a dynamically allocated
memory that gets freed after use.

[xiyou.wangcong@gmail.com: remove a useless kfree()]

Signed-off-by: Ignacy Gawędzki 
Signed-off-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

pktgen: fix UDP checksum computation

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

[ Upstream commit 7744b5f3693cc06695cb9d6667671c790282730f ]

This patch fixes two issues in UDP checksum computation in pktgen.

First, the pseudo-header uses the source and destination IP
addresses. Currently, the ports are used for IPv4.

Second, the UDP checksum covers both header and data.  So we need to
generate the data earlier (move pktgen_finalize_skb up), and compute
the checksum for UDP header + data.

Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums")
Signed-off-by: Sabrina Dubroca 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

flowcache: Fix kernel panic in flow_cache_flush_task

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

[ Upstream commit 233c96fc077d310772375d47522fb444ff546905 ]

flow_cache_flush_task references a structure member flow_cache_gc_work
where it should reference flow_cache_flush_task instead.

Kernel panic occurs on kernels using IPsec during XFRM garbage
collection. The garbage collection interval can be shortened using the
following sysctl settings:

net.ipv4.xfrm4_gc_thresh=4
net.ipv6.xfrm6_gc_thresh=4

With the default settings, our productions servers crash approximately
once a week. With the settings above, they crash immediately.

Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
Reported-by: Tomáš Charvát 
Tested-by: Jan Hejl 
Signed-off-by: Miroslav Urbanek 
Acked-by: Eric Dumazet 
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