linux, branch v3.7.8

Linux 3.7.8

2013-02-14T18:57:59Z

drm/nouveau: add lockdep annotations

2013-02-14T18:48:37Z

commit 5f97ab913cf0fbc378ea8ffc3ee66f4890d11c55 upstream. 1) Lockdep thinks all nouveau subdevs belong to the same class and can be locked in arbitrary order, which is not true (at least in general case). Tell it to distinguish subdevs by (o)class type. 2) DRM client can be locked under user client lock - tell lockdep to put DRM client lock in a separate class. Reported-by: Arend van Spriel Reported-by: Peter Hurley Reported-by: Maarten Lankhorst Reported-by: Daniel J Blueman Signed-off-by: Marcin Slusarz Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

net: splice: fix __splice_segment()

2013-02-14T18:48:37Z

[ Upstream commit bc9540c637c3d8712ccbf9dcf28621f380ed5e64 ] commit 9ca1b22d6d2 (net: splice: avoid high order page splitting) forgot that skb->head could need a copy into several page frags. This could be the case for loopback traffic mostly. Also remove now useless skb argument from linear_to_page() and __splice_segment() prototypes. Signed-off-by: Eric Dumazet Cc: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: splice: avoid high order page splitting

2013-02-14T18:48:37Z

[ Upstream commit 82bda6195615891181115f579a480aa5001ce7e9 ] splice() can handle pages of any order, but network code tries hard to split them in PAGE_SIZE units. Not quite successfully anyway, as __splice_segment() assumed poff < PAGE_SIZE. This is true for the skb->data part, not necessarily for the fragments. This patch removes this logic to give the pages as they are in the skb. Signed-off-by: Eric Dumazet Cc: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: fix splice() and tcp collapsing interaction

2013-02-14T18:48:36Z

[ Upstream commit f26845b43c75d3f32f98d194c1327b5b1e6b3fb0 ] Under unusual circumstances, TCP collapse can split a big GRO TCP packet while its being used in a splice(socket->pipe) operation. skb_splice_bits() releases the socket lock before calling splice_to_pipe(). [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc() [ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]- [ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13 To fix this problem, we must eat skbs in tcp_recv_skb(). Remove the inline keyword from tcp_recv_skb() definition since it has three call sites. Reported-by: Christian Becker Cc: Willy Tarreau Signed-off-by: Eric Dumazet Tested-by: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: splice: fix an infinite loop in tcp_read_sock()

2013-02-14T18:48:36Z

[ Upstream commit ff905b1e4aad8ccbbb0d42f7137f19482742ff07 ] commit 02275a2ee7c0 (tcp: don't abort splice() after small transfers) added a regression. [ 83.843570] INFO: rcu_sched self-detected stall on CPU [ 83.844575] INFO: rcu_sched detected stalls on CPUs/tasks: { 6} (detected by 0, t=21002 jiffies, g=4457, c=4456, q=13132) [ 83.844582] Task dump for CPU 6: [ 83.844584] netperf R running task 0 8966 8952 0x0000000c [ 83.844587] 0000000000000000 0000000000000006 0000000000006c6c 0000000000000000 [ 83.844589] 000000000000006c 0000000000000096 ffffffff819ce2bc ffffffffffffff10 [ 83.844592] ffffffff81088679 0000000000000010 0000000000000246 ffff880c4b9ddcd8 [ 83.844594] Call Trace: [ 83.844596] [] ? vprintk_emit+0x1c9/0x4c0 [ 83.844601] [] ? schedule+0x29/0x70 [ 83.844606] [] ? tcp_splice_data_recv+0x42/0x50 [ 83.844610] [] ? tcp_read_sock+0xda/0x260 [ 83.844613] [] ? tcp_prequeue_process+0xb0/0xb0 [ 83.844615] [] ? tcp_splice_read+0xc0/0x250 [ 83.844618] [] ? sock_splice_read+0x22/0x30 [ 83.844622] [] ? do_splice_to+0x7b/0xa0 [ 83.844627] [] ? sys_splice+0x59c/0x5d0 [ 83.844630] [] ? putname+0x2b/0x40 [ 83.844633] [] ? do_sys_open+0x174/0x1e0 [ 83.844636] [] ? system_call_fastpath+0x16/0x1b if recv_actor() returns 0, we should stop immediately, because looping wont give a chance to drain the pipe. Signed-off-by: Eric Dumazet Cc: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: don't abort splice() after small transfers

2013-02-14T18:48:36Z

[ Upstream commit 02275a2ee7c0ea475b6f4a6428f5df592bc9d30b ] TCP coalescing added a regression in splice(socket->pipe) performance, for some workloads because of the way tcp_read_sock() is implemented. The reason for this is the break when (offset + 1 != skb->len). As we released the socket lock, this condition is possible if TCP stack added a fragment to the skb, which can happen with TCP coalescing. So let's go back to the beginning of the loop when this happens, to give a chance to splice more frags per system call. Doing so fixes the issue and makes GRO 10% faster than LRO on CPU-bound splice() workloads instead of the opposite. Signed-off-by: Willy Tarreau Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: fix for zero packets_in_flight was too broad

2013-02-14T18:48:35Z

[ Upstream commit 6731d2095bd4aef18027c72ef845ab1087c3ba63 ] There are transients during normal FRTO procedure during which the packets_in_flight can go to zero between write_queue state updates and firing the resulting segments out. As FRTO processing occurs during that window the check must be more precise to not match "spuriously" :-). More specificly, e.g., when packets_in_flight is zero but FLAG_DATA_ACKED is true the problematic branch that set cwnd into zero would not be taken and new segments might be sent out later. Signed-off-by: Ilpo Järvinen Tested-by: Eric Dumazet Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: frto should not set snd_cwnd to 0

2013-02-14T18:48:35Z

[ Upstream commit 2e5f421211ff76c17130b4597bc06df4eeead24f ] Commit 9dc274151a548 (tcp: fix ABC in tcp_slow_start()) uncovered a bug in FRTO code : tcp_process_frto() is setting snd_cwnd to 0 if the number of in flight packets is 0. As Neal pointed out, if no packet is in flight we lost our chance to disambiguate whether a loss timeout was spurious. We should assume it was a proper loss. Reported-by: Pasi Kärkkäinen Signed-off-by: Neal Cardwell Signed-off-by: Eric Dumazet Cc: Ilpo Järvinen Cc: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: fix an infinite loop in tcp_slow_start()

2013-02-14T18:48:34Z

[ Upstream commit 973ec449bb4f2b8c514bacbcb4d9506fc31c8ce3 ] Since commit 9dc274151a548 (tcp: fix ABC in tcp_slow_start()), a nul snd_cwnd triggers an infinite loop in tcp_slow_start() Avoid this infinite loop and log a one time error for further analysis. FRTO code is suspected to cause this bug. Reported-by: Pasi Kärkkäinen Signed-off-by: Eric Dumazet Cc: Neal Cardwell Cc: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman