linux-toradex.git/net/core, branch v3.2.8-rt13

net: Avoid livelock in net_tx_action() on RT

2012-02-15T16:33:02+00:00

qdisc_lock is taken w/o disabling interrupts or bottom halfs. So code
holding a qdisc_lock() can be interrupted and softirqs can run on the
return of interrupt in !RT.

The spin_trylock() in net_tx_action() makes sure, that the softirq
does not deadlock. When the lock can't be acquired q is requeued and
the NET_TX softirq is raised. That causes the softirq to run over and
over.

That works in mainline as do_softirq() has a retry loop limit and
leaves the softirq processing in the interrupt return path and
schedules ksoftirqd. The task which holds qdisc_lock cannot be
preempted, so the lock is released and either ksoftirqd or the next
softirq in the return from interrupt path can proceed. Though it's a
bit strange to actually run MAX_SOFTIRQ_RESTART (10) loops before it
decides to bail out even if it's clear in the first iteration :)

On RT all softirq processing is done in a FIFO thread and we don't
have a loop limit, so ksoftirqd preempts the lock holder forever and
unqueues and requeues until the reset button is hit.

Due to the forced threading of ksoftirqd on RT we actually cannot
deadlock on qdisc_lock because it's a "sleeping lock". So it's safe to
replace the spin_trylock() with a spin_lock(). When contended,
ksoftirqd is scheduled out and the lock holder can proceed.

[ tglx: Massaged changelog and code comments ]

Solved-by: Thomas Gleixner 
Signed-off-by: Steven Rostedt 
Tested-by: Carsten Emde 
Cc: Clark Williams 
Cc: John Kacur 
Cc: Luis Claudio R. Goncalves 
Signed-off-by: Thomas Gleixner

skbufhead-raw-lock.patch

2012-02-15T16:33:00+00:00

Signed-off-by: Thomas Gleixner

net-netif_rx_ni-migrate-disable.patch

2012-02-15T16:32:51+00:00

Signed-off-by: Thomas Gleixner

softirq-thread-do-softirq.patch

2012-02-15T16:32:34+00:00

Signed-off-by: Thomas Gleixner

net-flip-lock-dep-thingy.patch

2012-02-15T16:32:34+00:00

=======================================================
[ INFO: possible circular locking dependency detected ]
3.0.0-rc3+ #26
-------------------------------------------------------
ip/1104 is trying to acquire lock:
 (local_softirq_lock){+.+...}, at: [] __local_lock+0x25/0x68

but task is already holding lock:
 (sk_lock-AF_INET){+.+...}, at: [] lock_sock+0x10/0x12

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (sk_lock-AF_INET){+.+...}:
       [] lock_acquire+0x103/0x12e
       [] lock_sock_nested+0x82/0x92
       [] lock_sock+0x10/0x12
       [] tcp_close+0x1b/0x355
       [] inet_release+0xc3/0xcd
       [] sock_release+0x1f/0x74
       [] sock_close+0x27/0x2b
       [] fput+0x11d/0x1e3
       [] filp_close+0x70/0x7b
       [] sys_close+0xf8/0x13d
       [] system_call_fastpath+0x16/0x1b

-> #0 (local_softirq_lock){+.+...}:
       [] __lock_acquire+0xacc/0xdc8
       [] lock_acquire+0x103/0x12e
       [] _raw_spin_lock+0x3b/0x4a
       [] __local_lock+0x25/0x68
       [] local_bh_disable+0x36/0x3b
       [] _raw_write_lock_bh+0x16/0x4f
       [] tcp_close+0x159/0x355
       [] inet_release+0xc3/0xcd
       [] sock_release+0x1f/0x74
       [] sock_close+0x27/0x2b
       [] fput+0x11d/0x1e3
       [] filp_close+0x70/0x7b
       [] sys_close+0xf8/0x13d
       [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(sk_lock-AF_INET);
                               lock(local_softirq_lock);
                               lock(sk_lock-AF_INET);
  lock(local_softirq_lock);

 *** DEADLOCK ***

1 lock held by ip/1104:
 #0:  (sk_lock-AF_INET){+.+...}, at: [] lock_sock+0x10/0x12

stack backtrace:
Pid: 1104, comm: ip Not tainted 3.0.0-rc3+ #26
Call Trace:
 [] print_circular_bug+0x1f8/0x209
 [] __lock_acquire+0xacc/0xdc8
 [] ? __local_lock+0x25/0x68
 [] lock_acquire+0x103/0x12e
 [] ? __local_lock+0x25/0x68
 [] ? get_parent_ip+0x11/0x41
 [] _raw_spin_lock+0x3b/0x4a
 [] ? __local_lock+0x25/0x68
 [] ? get_parent_ip+0x28/0x41
 [] __local_lock+0x25/0x68
 [] local_bh_disable+0x36/0x3b
 [] ? lock_sock+0x10/0x12
 [] _raw_write_lock_bh+0x16/0x4f
 [] tcp_close+0x159/0x355
 [] inet_release+0xc3/0xcd
 [] sock_release+0x1f/0x74
 [] sock_close+0x27/0x2b
 [] fput+0x11d/0x1e3
 [] filp_close+0x70/0x7b
 [] sys_close+0xf8/0x13d
 [] system_call_fastpath+0x16/0x1b


Signed-off-by: Thomas Gleixner

net: reintroduce missing rcu_assign_pointer() calls

2012-02-03T17:22:20+00:00

[ Upstream commit cf778b00e96df6d64f8e21b8395d1f8a859ecdc7 ]

commit a9b3cd7f32 (rcu: convert uses of rcu_assign_pointer(x, NULL) to
RCU_INIT_POINTER) did a lot of incorrect changes, since it did a
complete conversion of rcu_assign_pointer(x, y) to RCU_INIT_POINTER(x,
y).

We miss needed barriers, even on x86, when y is not NULL.

Signed-off-by: Eric Dumazet 
CC: Stephen Hemminger 
CC: Paul E. McKenney 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netns: fix net_alloc_generic()

2012-02-03T17:22:17+00:00

[ Upstream commit 073862ba5d249c20bd5c49fc6d904ff0e1f6a672 ]

When a new net namespace is created, we should attach to it a "struct
net_generic" with enough slots (even empty), or we can hit the following
BUG_ON() :

[  200.752016] kernel BUG at include/net/netns/generic.h:40!
...
[  200.752016]  [] ? get_cfcnfg+0x3a/0x180
[  200.752016]  [] ? lockdep_rtnl_is_held+0x10/0x20
[  200.752016]  [] caif_device_notify+0x2e/0x530
[  200.752016]  [] notifier_call_chain+0x67/0x110
[  200.752016]  [] raw_notifier_call_chain+0x11/0x20
[  200.752016]  [] call_netdevice_notifiers+0x32/0x60
[  200.752016]  [] register_netdevice+0x196/0x300
[  200.752016]  [] register_netdev+0x19/0x30
[  200.752016]  [] loopback_net_init+0x4a/0xa0
[  200.752016]  [] ops_init+0x42/0x180
[  200.752016]  [] setup_net+0x6b/0x100
[  200.752016]  [] copy_net_ns+0x86/0x110
[  200.752016]  [] create_new_namespaces+0xd9/0x190

net_alloc_generic() should take into account the maximum index into the
ptr array, as a subsystem might use net_generic() anytime.

This also reduces number of reallocations in net_assign_generic()

Reported-by: Sasha Levin 
Tested-by: Sasha Levin 
Signed-off-by: Eric Dumazet 
Cc: Sjur Brændeland 
Cc: Eric W. Biederman 
Cc: Pavel Emelyanov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: relax rcvbuf limits

2011-12-23T07:15:14+00:00

skb->truesize might be big even for a small packet.

Its even bigger after commit 87fb4b7b533 (net: more accurate skb
truesize) and big MTU.

We should allow queueing at least one packet per receiver, even with a
low RCVBUF setting.

Reported-by: Michal Simek 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()

2011-12-23T03:34:56+00:00

Setting a large rps_flow_cnt like (1 << 30) on 32-bit platform will
cause a kernel oops due to insufficient bounds checking.

	if (count > 1<<30) {
		/* Enforce a limit to prevent overflow */
		return -EINVAL;
	}
	count = roundup_pow_of_two(count);
	table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count));

Note that the macro RPS_DEV_FLOW_TABLE_SIZE(count) is defined as:

	... + (count * sizeof(struct rps_dev_flow))

where sizeof(struct rps_dev_flow) is 8.  (1 << 30) * 8 will overflow
32 bits.

This patch replaces the magic number (1 << 30) with a symbolic bound.

Suggested-by: Eric Dumazet 
Signed-off-by: Xi Wang 
Signed-off-by: David S. Miller

net: Add a flow_cache_flush_deferred function

2011-12-21T21:48:08+00:00

flow_cach_flush() might sleep but can be called from
atomic context via the xfrm garbage collector. So add
a flow_cache_flush_deferred() function and use this if
the xfrm garbage colector is invoked from within the
packet path.

Signed-off-by: Steffen Klassert 
Acked-by: Timo Teräs 
Signed-off-by: David S. Miller