linux-toradex.git/net, branch v3.2.9-rt16

ping-sysrq.patch

2012-03-06T16:18:00+00:00

There are (probably rare) situations when a system crashed and the system
console becomes unresponsive but the network icmp layer still is alive.
Wouldn't it be wonderful, if we then could submit a sysreq command via ping?

This patch provides this facility. Please consult the updated documentation
Documentation/sysrq.txt for details.

Signed-off-by: Carsten Emde

net: Avoid livelock in net_tx_action() on RT

2012-03-06T16:18:00+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-06T16:17:59+00:00

Signed-off-by: Thomas Gleixner

net-netif_rx_ni-migrate-disable.patch

2012-03-06T16:17:52+00:00

Signed-off-by: Thomas Gleixner

net-ipv4-route-use-locks-on-up-rt.patch

2012-03-06T16:17:45+00:00

Signed-off-by: Thomas Gleixner

net-wireless-warn-nort.patch

2012-03-06T16:17:40+00:00

Signed-off-by: Thomas Gleixner

softirq-thread-do-softirq.patch

2012-03-06T16:17:35+00:00

Signed-off-by: Thomas Gleixner

net-flip-lock-dep-thingy.patch

2012-03-06T16:17:35+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

fs: dentry use seqlock

2012-03-06T16:17:29+00:00

Replace the open coded seqlock with a real seqlock, so RT can handle
it.

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

ipvs: fix matching of fwmark templates during scheduling

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

commit e0aac52e17a3db68fe2ceae281780a70fc69957f upstream.

	Commit f11017ec2d1859c661f4e2b12c4a8d250e1f47cf (2.6.37)
moved the fwmark variable in subcontext that is invalidated before
reaching the ip_vs_ct_in_get call. As vaddr is provided as pointer
in the param structure make sure the fwmark variable is in
same context. As the fwmark templates can not be matched,
more and more template connections are created and the
controlled connections can not go to single real server.

Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman