linux/net, branch v3.0.3

atm: br2864: sent packets truncated in VC routed mode

2011-08-17T17:55:52Z

commit a08af810cdc29d2ca930e8a869d3d01744c392d8 upstream. Reported-by: Pascal Hambourg Signed-off-by: Chas Williams Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

gre: fix improper error handling

2011-08-16T01:31:39Z

[ Upstream commit 559fafb94ad9e4cd8774f39241917c57396f9fc5 ] Fix improper protocol err_handler, current implementation is fully unapplicable and may cause kernel crash due to double kfree_skb. Signed-off-by: Dmitry Kozlov Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv4: use RT_TOS after some rt_tos conversions

2011-08-16T01:31:39Z

[ Upstream commit b0fe4a31849063fcac0bdc93716ca92615e93f57 ] rt_tos was changed to iph->tos but it must be filtered by RT_TOS Signed-off-by: Julian Anastasov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: allow netif_carrier to be called safely from IRQ

2011-08-16T01:31:39Z

[ Upstream commit 1821f7cd65ad9ea56580b830ac79bf4c4fef59cb ] As reported by Ben Greer and Froncois Romieu. The code path in the netif_carrier code leads it to try and disable a late workqueue to reenable it immediately netif_carrier_on -> linkwatch_fire_event -> linkwatch_schedule_work -> cancel_delayed_work -> del_timer_sync If __cancel_delayed_work is used instead then there is no problem of waiting for running linkwatch_event. There is a race between linkwatch_event running re-scheduling but it is harmless to schedule an extra scan of the linkwatch queue. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

xfrm: Fix key lengths for rfc3686(ctr(aes))

2011-08-16T01:31:39Z

[ Upstream commit 4203223a1aed862b4445fdcd260d6139603a51d9 ] Fix the min and max bit lengths for AES-CTR (RFC3686) keys. The number of bits in key spec is the key length (128/256) plus 32 bits of nonce. This change takes care of the "Invalid key length" errors reported by setkey when specifying 288 bit keys for aes-ctr. Signed-off-by: Tushar Gohad Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared

2011-08-16T01:31:38Z

[ Upstream commit 550fd08c2cebad61c548def135f67aba284c6162 ] After the last patch, We are left in a state in which only drivers calling ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real hardware call ether_setup for their net_devices and don't hold any state in their skbs. There are a handful of drivers that violate this assumption of course, and need to be fixed up. This patch identifies those drivers, and marks them as not being able to support the safe transmission of skbs by clearning the IFF_TX_SKB_SHARING flag in priv_flags Signed-off-by: Neil Horman CC: Karsten Keil CC: "David S. Miller" CC: Jay Vosburgh CC: Andy Gospodarek CC: Patrick McHardy CC: Krzysztof Halasa CC: "John W. Linville" CC: Greg Kroah-Hartman CC: Marcel Holtmann CC: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: add IFF_SKB_TX_SHARED flag to priv_flags

2011-08-16T01:31:38Z

[ Upstream commit d8873315065f1f527c7c380402cf59b1e1d0ae36 ] Pktgen attempts to transmit shared skbs to net devices, which can't be used by some drivers as they keep state information in skbs. This patch adds a flag marking drivers as being able to handle shared skbs in their tx path. Drivers are defaulted to being unable to do so, but calling ether_setup enables this flag, as 90% of the drivers calling ether_setup touch real hardware and can handle shared skbs. A subsequent patch will audit drivers to ensure that the flag is set properly Signed-off-by: Neil Horman Reported-by: Jiri Pirko CC: Robert Olsson CC: Eric Dumazet CC: Alexey Dobriyan CC: David S. Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

IPv4: Send gratuitous ARP for secondary IP addresses also

2011-08-16T01:31:38Z

[ Upstream commit b76d0789c92a816a5539dc14232a700b8d62a53a ] If a device event generates gratuitous ARP messages, only primary address is used for sending. This patch iterates through the whole list. Tested with 2 IP addresses configuration on bonding interface. Signed-off-by: Zoltan Kiss Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

sch_sfq: fix sfq_enqueue()

2011-08-16T01:31:38Z

[ Upstream commit e1738bd9cecc5c867b0e2996470c1ff20f66ba79 ] commit 8efa88540635 (sch_sfq: avoid giving spurious NET_XMIT_CN signals) forgot to call qdisc_tree_decrease_qlen() to signal upper levels that a packet (from another flow) was dropped, leading to various problems. With help from Michal Soltys and Michal Pokrywka, who did a bisection. Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=39372 Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945 Reported-by: Lucas Bocchi Reported-and-bisected-by: Michal Pokrywka Signed-off-by: Eric Dumazet CC: Michal Soltys Acked-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: adjust array index

2011-08-16T01:31:37Z

[ Upstream commit a1889c0d2039a53ae04abb9f20c62500bd312bf3 ] Convert array index from the loop bound to the loop index. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2,ar; @@ for(e1 = 0; e1 < e2; e1++) { <... ar[ - e2 + e1 ] ...> } // Signed-off-by: Julia Lawall Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman