From: Greg Kroah-Hartman Date: Thu, 25 Oct 2012 22:45:08 +0000 (-0700) Subject: 3.0-stable patches X-Git-Tag: v3.0.49~29 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6485888c782c853e2bb20fca5b7a4c0548ef8152;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0-stable patches added patches: net-fix-skb_under_panic-oops-in-neigh_resolve_output.patch rds-fix-rds-ping-spinlock-recursion.patch skge-add-dma-mask-quirk-for-marvell-88e8001-on-asus-p5nsli-motherboard.patch tcp-resets-are-misrouted.patch --- diff --git a/queue-3.0/net-fix-skb_under_panic-oops-in-neigh_resolve_output.patch b/queue-3.0/net-fix-skb_under_panic-oops-in-neigh_resolve_output.patch new file mode 100644 index 00000000000..58db5f6d12e --- /dev/null +++ b/queue-3.0/net-fix-skb_under_panic-oops-in-neigh_resolve_output.patch @@ -0,0 +1,55 @@ +From 9de183117bbfb6fb7f686c15468bd0290adbcdec Mon Sep 17 00:00:00 2001 +From: "ramesh.nagappa@gmail.com" +Date: Fri, 5 Oct 2012 19:10:15 +0000 +Subject: net: Fix skb_under_panic oops in neigh_resolve_output + + +From: "ramesh.nagappa@gmail.com" + +[ Upstream commit e1f165032c8bade3a6bdf546f8faf61fda4dd01c ] + +The retry loop in neigh_resolve_output() and neigh_connected_output() +call dev_hard_header() with out reseting the skb to network_header. +This causes the retry to fail with skb_under_panic. The fix is to +reset the network_header within the retry loop. + +Signed-off-by: Ramesh Nagappa +Reviewed-by: Shawn Lu +Reviewed-by: Robert Coulson +Reviewed-by: Billie Alsup +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/core/neighbour.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/net/core/neighbour.c ++++ b/net/core/neighbour.c +@@ -1313,8 +1313,6 @@ int neigh_resolve_output(struct sk_buff + if (!dst) + goto discard; + +- __skb_pull(skb, skb_network_offset(skb)); +- + if (!neigh_event_send(neigh, skb)) { + int err; + struct net_device *dev = neigh->dev; +@@ -1326,6 +1324,7 @@ int neigh_resolve_output(struct sk_buff + neigh_hh_init(neigh, dst, dst->ops->protocol); + + do { ++ __skb_pull(skb, skb_network_offset(skb)); + seq = read_seqbegin(&neigh->ha_lock); + err = dev_hard_header(skb, dev, ntohs(skb->protocol), + neigh->ha, NULL, skb->len); +@@ -1358,9 +1357,8 @@ int neigh_connected_output(struct sk_buf + struct net_device *dev = neigh->dev; + unsigned int seq; + +- __skb_pull(skb, skb_network_offset(skb)); +- + do { ++ __skb_pull(skb, skb_network_offset(skb)); + seq = read_seqbegin(&neigh->ha_lock); + err = dev_hard_header(skb, dev, ntohs(skb->protocol), + neigh->ha, NULL, skb->len); diff --git a/queue-3.0/rds-fix-rds-ping-spinlock-recursion.patch b/queue-3.0/rds-fix-rds-ping-spinlock-recursion.patch new file mode 100644 index 00000000000..71ea818b9b1 --- /dev/null +++ b/queue-3.0/rds-fix-rds-ping-spinlock-recursion.patch @@ -0,0 +1,46 @@ +From 9251a9ca0a8317a1abf8c06f385507a685ef4b7c Mon Sep 17 00:00:00 2001 +From: "jeff.liu" +Date: Mon, 8 Oct 2012 18:57:27 +0000 +Subject: RDS: fix rds-ping spinlock recursion + + +From: "jeff.liu" + +[ Upstream commit 5175a5e76bbdf20a614fb47ce7a38f0f39e70226 ] + +This is the revised patch for fixing rds-ping spinlock recursion +according to Venkat's suggestions. + +RDS ping/pong over TCP feature has been broken for years(2.6.39 to +3.6.0) since we have to set TCP cork and call kernel_sendmsg() between +ping/pong which both need to lock "struct sock *sk". However, this +lock has already been hold before rds_tcp_data_ready() callback is +triggerred. As a result, we always facing spinlock resursion which +would resulting in system panic. + +Given that RDS ping is only used to test the connectivity and not for +serious performance measurements, we can queue the pong transmit to +rds_wq as a delayed response. + +Reported-by: Dan Carpenter +CC: Venkat Venkatsubra +CC: David S. Miller +CC: James Morris +Signed-off-by: Jie Liu +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/rds/send.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/rds/send.c ++++ b/net/rds/send.c +@@ -1121,7 +1121,7 @@ rds_send_pong(struct rds_connection *con + rds_stats_inc(s_send_pong); + + if (!test_bit(RDS_LL_SEND_FULL, &conn->c_flags)) +- rds_send_xmit(conn); ++ queue_delayed_work(rds_wq, &conn->c_send_w, 0); + + rds_message_put(rm); + return 0; diff --git a/queue-3.0/series b/queue-3.0/series index e9e07b4bf04..1998bb858e9 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -16,3 +16,7 @@ cgroup-notify_on_release-may-not-be-triggered-in-some-cases.patch amd64_edac-__amd64_set_scrub_rate-avoid-overindexing-scrubrates.patch media-au0828-fix-case-where-streamoff-being-called-on-stopped-stream-causes-bug.patch drm-i915-apply-timing-generator-bug-workaround-on-cpt-and-ppt.patch +net-fix-skb_under_panic-oops-in-neigh_resolve_output.patch +skge-add-dma-mask-quirk-for-marvell-88e8001-on-asus-p5nsli-motherboard.patch +rds-fix-rds-ping-spinlock-recursion.patch +tcp-resets-are-misrouted.patch diff --git a/queue-3.0/skge-add-dma-mask-quirk-for-marvell-88e8001-on-asus-p5nsli-motherboard.patch b/queue-3.0/skge-add-dma-mask-quirk-for-marvell-88e8001-on-asus-p5nsli-motherboard.patch new file mode 100644 index 00000000000..46a0937c9d1 --- /dev/null +++ b/queue-3.0/skge-add-dma-mask-quirk-for-marvell-88e8001-on-asus-p5nsli-motherboard.patch @@ -0,0 +1,46 @@ +From dd662994f0d9c7afe74ad2a84ce1bf1cd62cdae5 Mon Sep 17 00:00:00 2001 +From: Graham Gower +Date: Mon, 8 Oct 2012 08:34:50 +0000 +Subject: skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard + + +From: Graham Gower + +[ Upstream commit a2af139ff1cd85df586690ff626619ab1ee88b0a ] + +Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive +packets on a system with >4gb ram unless a 32bit DMA mask is used. + +This issue has been around for years and a fix was sent 3.5 years ago, but +there was some debate as to whether it should instead be fixed as a PCI quirk. +http://www.spinics.net/lists/netdev/msg88670.html + +However, 18 months later a similar workaround was introduced for another +chipset exhibiting the same problem. +http://www.spinics.net/lists/netdev/msg142287.html + +Signed-off-by: Graham Gower +Signed-off-by: Jan Ceuleers +Acked-by: Stephen Hemminger +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/skge.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/net/skge.c ++++ b/drivers/net/skge.c +@@ -4097,6 +4097,13 @@ static struct dmi_system_id skge_32bit_d + DMI_MATCH(DMI_BOARD_NAME, "nForce"), + }, + }, ++ { ++ .ident = "ASUS P5NSLI", ++ .matches = { ++ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."), ++ DMI_MATCH(DMI_BOARD_NAME, "P5NSLI") ++ }, ++ }, + {} + }; + diff --git a/queue-3.0/tcp-resets-are-misrouted.patch b/queue-3.0/tcp-resets-are-misrouted.patch new file mode 100644 index 00000000000..77b9df5ad7f --- /dev/null +++ b/queue-3.0/tcp-resets-are-misrouted.patch @@ -0,0 +1,66 @@ +From 8edd71585ed6f48c198cbed5d642e021a3b56cbf Mon Sep 17 00:00:00 2001 +From: Alexey Kuznetsov +Date: Fri, 12 Oct 2012 04:34:17 +0000 +Subject: tcp: resets are misrouted + + +From: Alexey Kuznetsov + +[ Upstream commit 4c67525849e0b7f4bd4fab2487ec9e43ea52ef29 ] + +After commit e2446eaa ("tcp_v4_send_reset: binding oif to iif in no +sock case").. tcp resets are always lost, when routing is asymmetric. +Yes, backing out that patch will result in misrouting of resets for +dead connections which used interface binding when were alive, but we +actually cannot do anything here. What's died that's died and correct +handling normal unbound connections is obviously a priority. + +Comment to comment: +> This has few benefits: +> 1. tcp_v6_send_reset already did that. + +It was done to route resets for IPv6 link local addresses. It was a +mistake to do so for global addresses. The patch fixes this as well. + +Actually, the problem appears to be even more serious than guaranteed +loss of resets. As reported by Sergey Soloviev , those +misrouted resets create a lot of arp traffic and huge amount of +unresolved arp entires putting down to knees NAT firewalls which use +asymmetric routing. + +Signed-off-by: Alexey Kuznetsov +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/tcp_ipv4.c | 7 ++++--- + net/ipv6/tcp_ipv6.c | 3 ++- + 2 files changed, 6 insertions(+), 4 deletions(-) + +--- a/net/ipv4/tcp_ipv4.c ++++ b/net/ipv4/tcp_ipv4.c +@@ -651,10 +651,11 @@ static void tcp_v4_send_reset(struct soc + arg.csumoffset = offsetof(struct tcphdr, check) / 2; + arg.flags = (sk && inet_sk(sk)->transparent) ? IP_REPLY_ARG_NOSRCCHECK : 0; + /* When socket is gone, all binding information is lost. +- * routing might fail in this case. using iif for oif to +- * make sure we can deliver it ++ * routing might fail in this case. No choice here, if we choose to force ++ * input interface, we will misroute in case of asymmetric route. + */ +- arg.bound_dev_if = sk ? sk->sk_bound_dev_if : inet_iif(skb); ++ if (sk) ++ arg.bound_dev_if = sk->sk_bound_dev_if; + + net = dev_net(skb_dst(skb)->dev); + ip_send_reply(net->ipv4.tcp_sock, skb, ip_hdr(skb)->saddr, +--- a/net/ipv6/tcp_ipv6.c ++++ b/net/ipv6/tcp_ipv6.c +@@ -1060,7 +1060,8 @@ static void tcp_v6_send_response(struct + __tcp_v6_send_check(buff, &fl6.saddr, &fl6.daddr); + + fl6.flowi6_proto = IPPROTO_TCP; +- fl6.flowi6_oif = inet6_iif(skb); ++ if (ipv6_addr_type(&fl6.daddr) & IPV6_ADDR_LINKLOCAL) ++ fl6.flowi6_oif = inet6_iif(skb); + fl6.fl6_dport = t1->dest; + fl6.fl6_sport = t1->source; + security_skb_classify_flow(skb, flowi6_to_flowi(&fl6));