linux-toradex.git/net/core, branch v3.2.11-rt20

softirq: Check preemption after reenabling interrupts

2012-03-14T15:50:16+00:00

raise_softirq_irqoff() disables interrupts and wakes the softirq
daemon, but after reenabling interrupts there is no preemption check,
so the execution of the softirq thread might be delayed arbitrarily.

In principle we could add that check to local_irq_enable/restore, but
that's overkill as the rasie_softirq_irqoff() sections are the only
ones which show this behaviour.

Reported-by: Carsten Emde 
Signed-off-by: Thomas Gleixner 
Cc: stable-rt@vger.kernel.org

net: Avoid livelock in net_tx_action() on RT

2012-03-14T15:50:13+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-03-14T15:50:12+00:00

Signed-off-by: Thomas Gleixner

net-netif_rx_ni-migrate-disable.patch

2012-03-14T15:50:05+00:00

Signed-off-by: Thomas Gleixner

softirq-thread-do-softirq.patch

2012-03-14T15:49:48+00:00

Signed-off-by: Thomas Gleixner

net-flip-lock-dep-thingy.patch

2012-03-14T15:49:48+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

gro: more generic L2 header check

2012-03-01T00:31:04+00:00

[ Upstream commit 5ca3b72c5da47d95b83857b768def6172fbc080a ]

Shlomo Pongratz reported GRO L2 header check was suited for Ethernet
only, and failed on IB/ipoib traffic.

He provided a patch faking a zeroed header to let GRO aggregates frames.

Roland Dreier, Herbert Xu, and others suggested we change GRO L2 header
check to be more generic, ie not assuming L2 header is 14 bytes, but
taking into account hard_header_len.

__napi_gro_receive() has special handling for the common case (Ethernet)
to avoid a memcmp() call and use an inline optimized function instead.

Signed-off-by: Eric Dumazet 
Reported-by: Shlomo Pongratz 
Cc: Roland Dreier 
Cc: Or Gerlitz 
Cc: Herbert Xu 
Tested-by: Sean Hefty 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netpoll: netpoll_poll_dev() should access dev->flags

2012-03-01T00:30:58+00:00

[ Upstream commit 58e05f357a039a94aa36475f8c110256f693a239 ]

commit 5a698af53f (bond: service netpoll arp queue on master device)
tested IFF_SLAVE flag against dev->priv_flags instead of dev->flags

Signed-off-by: Eric Dumazet 
Cc: WANG Cong 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

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